The docs for the timeit command line interface specify If -n is not given, a suitable number of loops is calculated by trying successive powers of 10 until the total time is at least 0.2 seconds. This sounds as if it it first tries 1, then 10, then 100 etc. But the code starts with 10 iterations. So even if the tested code already takes long enough (e.g. because it is a suitable loop itself), timit will by default test 10 loops. I propose to change that, and replace # determine number so that 0.2 <= total time < 2.0 for i in range(1, 10): number = 10**i with # determine number so that 0.2 <= total time < 2.0 for i in range(0, 10): number = 10**i in Lib/timeit.py.
Huh. I assumed that timeit was doing this already. +1 from me. Affects Python 3.4 and 3.5, too. taniyama:~ mdickinson$ time python -m timeit "import time; time.sleep(1.0)" 10 loops, best of 3: 1 sec per loop real 0m40.165s user 0m0.040s sys 0m0.024s
I don't know what happened to this issue, but it looks good to me. So here is a patch for it as Joachim suggested. $ time ./python -m timeit "import time; time.sleep(1.0)" 1 loops, best of 3: 1 sec per loop real 0m4.134s user 0m0.116s sys 0m0.004s
Then maybe the docs should be clarified. "If -n is not given, a suitable number of loops is calculated by trying successive powers of 10 (starting from 10) until the total time is at least 0.2 seconds."
That was implemented in . $ time ./python -m timeit "import time; time.sleep(1.0)" 1 loop, best of 5: 1 sec per loop real 0m6.176s user 0m0.160s sys 0m0.004s
