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

Thomas Wouters thomas at python.org
Wed May 24 12:52:25 CEST 2006


On 5/24/06, Tim Peters <tim.peters at gmail.com> wrote:

> time.clock() has sub-microsecond resolution (better than a millionth of a
> second) on all flavors of Windows.
>
> time.time() has poor resolution on all flavors of Windows, and is
> extraordinarily expensive to call on some flavors of Windows.  The
> resolution depends in part on HW configuration.  Most common are updating
> 18.2 times per second (0.055 second resolution) or 100 times per second (
> 0.01 second resolution).  As a result, if you call time.time() twice in a
> row on Windows, it's likely you'll get exactly the same value both times.


Is there any particular reason we don't implement time.time() in terms of
time.clock() (or rather, the same underlying mechanism?) Seed it once with
ftime or gettimeofday or whatever's best on Windows, then use the
performance counters to keep track of elapsed time? It wouldn't provide more
accurate absolute time (and indeed, slightly more inaccurate, depending on
howlong it takes between the two calls), but it would provide more accurate
time-differences (as far as I understand.)

Or is time.time(), in spite of being extraordinarily expensive, still faster
than time.clock()? Or is time.clock() unreasonably bounded?

Aren't-half-liter-coke-cans-great'ly y'rs,
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-checkins/attachments/20060524/e0a06a38/attachment.html 


More information about the Python-checkins mailing list