[Python-checkins] r46146 - sandbox/trunk/rjsh-pybench/pybench.py

[Tim Peters]

[M.-A. Lemburg]
> ..
> I understand, I would just like to have a good and
> reliable timer used in pybench.
>
> On Unix (which I use most the time), time.clock() gives
> reasonable and repeatable results, so it's the
> obvious choice.
>
> On Windows, it seems that we should try to come up with
> a better alternative to time.clock(). I'll give that a shot
> later today.

> ...
> I'm not sure where timeit.py originated, but yes, it's
> certainly doing the wrong thing on Unix.

No.  The real proof is in the pudding:  timeit.py is also heavily and
happily used on Linux.  It's not some distinction between "wall-clock
time" and "CPU tijme" timeit.py cares about, it's the underlying
timer's _resolution_, whatever it's measuring.  time.clock() typically
has poor resolution on Linux (as does time.time() on Windows), and
that's the real reason timeit.py uses time.clock() on Windows but
time.time() on Linux.  The good _resolution_ of those timers allows
running simple tests for a much shorter amount of total time without
introducing gross quantification errors due to poor resolution.
Running for a shorter total amount of time in turn makes timing tests
go faster, and reduces chances for gross interference.  Running
several times and reporting the minimum time taken is then usually
effective at filtering out whatever gross interference may have
occurred during some run(s).

Since timeit.py aims at small, fast-running code segments, it's doing
exactly the right thing for that purpose.  If a Windows process-time
gimmick were added, timeit.py would not want to use it (unless its
_resolution_ was better than the Windows time.clock()).