[Python-Dev] Drop the new time.wallclock() function? (original) (raw)

Guido van Rossum guido at python.org
Wed Mar 14 17:22:36 CET 2012

I have a totally different observation. Presumably the primary use case for these timers is to measure real time intervals for the purpose of profiling various operations. For this purpose we want them to be as "steady" as possible: tick at a constant rate, don't jump forward or backward. (And they shouldn't invoke the concept of "CPU" time -- we already have time.clock() for that, besides it's often wrong, e.g. you might be measuring some sort of I/O performance.) If this means that a second as measured by time.time() is sometimes not the same as a second measured by this timer (due to time.time() occasionally jumping due to clock adjustments), that's fine with me. If this means it's unreliable inside a VM, well, it seems that's a property of the underlying OS timer, and there's not much we can do about it except letting a knowledgeable user override the timer user. As for names, I like Jeffrey's idea of having "steady" in the name.

--Guido

On Wed, Mar 14, 2012 at 9:11 AM, Matt Joiner <anacrolix at gmail.com> wrote:

I have some observations regarding this:

Victor's existing time.monotonic and time.wallclock make use of QueryPerformanceCounter, and CLOCKMONOTONICRAW as possible. Both of these are hardware-based counters, their monotonicity is just a convenient property of the timer sources. Furthermore, time values can actually vary depending on the processor the call is served on. time.hardware()? time.monotonicraw()? There are bug reports on Linux that CLOCKMONOTONIC isn't always monotonic. This is why CLOCKMONOTONICRAW was created. There's also the issue of time leaps (forward), which also isn't a problem with the latter form. time.monotonic(rawonly=False)? The real value of "monotonic" timers is that they don't leap backwards, and preferably don't leap forwards. Whether they are absolute is of no consequence. I would suggest that the API reflect this, and that more specific time values be obtained using the proper raw syscall wrapper (like time.clockgettime) if required. time.relative(strict=False)? The ultimate use of the function name being established is for use in timeouts and relative timings. Where an option is present, it disallows fallbacks like CLOCKMONOTONIC and other weaker forms:  * time.hardware(fallback=True) -> reflects the source of the timing impeccably. alerts users to possible affinity issues  * time.monotonicraw() -> a bit linux specific...  * time.relative(strict=False) -> matches the use case. a warning could be put regarding hardware timings  * time.monotonic(rawonly=False) -> closest to the existing implementation. the keyword name i think is better.

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list