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

[Tim Peters]

[MAL]
> Sorry, but that approach is just plain wrong:
>
> if sys.platform == "win32":
>     # On Windows, the best timer is time.clock()
>     default_timer = time.clock
> else:
>     # On most other platforms the best timer is time.time()
>     default_timer = time.time
>
> You never want to use a wall clock timer to measure
> the speed of code execution.

You do on Windows, because the resolution of time.time() is unusably
crude.  Note that the code above was copied from Python's timeit.py,
which is heavily and happily used on Windows.

> There are simply too man other things going on in a multi-process
> system to make this a reliable approach.

That's life.  Windows people know to keep their machine as quiet as
possible when doing timings, and most Linux people know that too
despite that it's not supposed to necessary there ;-)

> On Unix time.clock() will give you process time which
> is far more reliable as it provides feedback on the
> time the process actually received from the kernel
> for execution.

This is understood by all.  Nevertheless, Unix time.clock() results
also vary across runs of identical code -- there is no _truly_
"reliable" approach on any box,  if "reliable" means "reproducible
without great care".

> According to MSDN it's only available on the WinNT branch
> of the Windows kernel. Since we're trying to optimize for
> a current system, it should be available on all systems
> where you'd normally be running pybench to check whether
> an optimization makes sense or not.

As noted before, "plain" Win2K is conspicuous by absence in the MSDN
docs for GetProcessTimes.