[Python-Dev] Conflict between time docs and timeit (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Fri Mar 18 12:07:04 CET 2011
- Previous message: [Python-Dev] Conflict between time docs and timeit
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 18 Mar 2011 17:06:50 +1100 Steven D'Aprano <steve at pearwood.info> wrote:
In contrast, timeit defaults to using time.time() under all operating systems other than Windows, and says: ...on Windows, clock() has microsecond granularity but time()'s granularity is 1/60th of a second; on Unix, clock() has 1/100th of a second granularity and time() is much more precise.
Should timeit be changed, or the docs, or have I missed something?
Well, time.clock() is less precise (in terms of timing granularity), but more accurate if the system if not otherwise idle - since it will report CPU time for the current process instead of total wall clock time, removing the direct contribution of other processes.
That said, benchmarks on a loaded system are inaccurate anyway, because of other factors (such as cost of context switching, TLB and cache misses, concurrent memory access from several processes).
I think a rule-of-thumb can be made:
- for short-running benchmarks (a couple of seconds at most), use time.time() which will give increased precision
- for longer-running benchmarks, use time.clock() (or the system's "time" command) which will avoid counting the runtime of other processes
timeit is in the former case.
(this is all about Unix, by the way)
Regards
Antoine.
- Previous message: [Python-Dev] Conflict between time docs and timeit
- Next message: [Python-Dev] Summary of Python tracker Issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]