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

[M.-A. Lemburg]

Tim Peters wrote:
> [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()).

Fair enough.

timeit.py then obviously has a different target and scope
than pybench.

pybench doesn't require a timer with a resolution of micro-seconds.
Instead it repeats the operation often enough to produce a total
test run-time of around 60 seconds per test. By measuring the
actual process time (at least on Unix and hopefully on Windows
too, once I have enough trust in the GetProcessTimes() API), it
minimizes effects related to other processes running in parallel.

I hope to find a slightly higher resolution timer than time.clock()
on Linux as well. resource.getrusage() seems to be a good candidate.

Perhaps we ought to create a new time module APIs usertime() and
systime() that use the platform specific APIs for these ?!

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 26 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2006-07-03: EuroPython 2006, CERN, Switzerland              37 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::