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

[Tim Peters]

[Thomas Wouters]
> 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.)

People who care about time differences on Windows should use
time.clock() directly, of course.  time.time() "should", e.g., reflect
differences due to synch'ing the system time-of-day clock with an
external time source, while time.clock() "should not".  They have
different purposes.

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

No, time.clock() is very cheap on most Windows boxes (it just reads up
the Pentium's real-time counter and packages the result).

> Or is time.clock() unreasonably bounded?

Not documented and don't know.  On Windows is the underlying source is
a 64-bit integer, but the units aren't defined (it's related to
whatever QueryPerformanceFrequency() happens to return).  While I
haven't seen it "wrap around", can't say that's impossible.