[Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()? (original) (raw)

Guido van Rossum guido at python.org
Sat Mar 31 00:21:32 CEST 2012

On Fri, Mar 30, 2012 at 2:43 PM, Cameron Simpson <cs at zip.com.au> wrote:

On 30Mar2012 13:52, Guido van Rossum <guido at python.org> wrote: | (In fact, this even argues against having both the timer with fallback | and the timer without fallback. So maybe we should just have a single | timer function, with fallback, and a separate mechanism to inquire | its properties.)

Well, you should be able to know what kind of clock you're getting. But what do to if you don't get a satisfactory one? There's then no way for ask for an alternative; you don't get to control the fallback method, for example. I've come to the opinion that the chosen approach is wrong, and suggest a better one. There seem to be a few competing features for clocks that people want:  - monotonic - never going backward at all  - high resolution  - no steps and only a few, fortunately. I think you're doing this wrong at the API level. People currently are expecting to call (for example) time.monotonic() (or whatever) and get back "now", a hopefully high resolution float. Given the subtlety sought for various purposes, people should be calling:  T = time.getclock(flags) and then later calling:  T.now() to get their float. That way people can:  - request a set of the three characteristics above  - inspect what they get back (it should have all the requested flags,  but unrequested flags may be set or not depending on the underlying  facility)  Obviously this should return None or raise an exception if the flag  set can't be met. Then users can request a less featured clock on failure, depending on what aspects of the clock are most desirable to their use case. Or of course fail if fallback is not satisfactory. Of course you can provide some convenient-with-fallback function that will let people do this in one hit without the need for "T", but it should not be the base facility offered. The base should let people request their feature set and inspect what is supplied.

I like this out-of-the-box thinking. But I'm still wondering if there really are enough flags for this to be worth it. If there are, great, the API is pretty. But if there are only 2 or 3 flag combinations that make actual sense, let's forget it.

Another out-of-the-box idea, going back to simplicity: have just one new function, time.hrtimer(), which is implemented using the highest-resolution timer available on the platform, but with no strong guarantees. It may jump, move back, drift, change its rate, or roll over occasionally. We try to use the implementation that's got the fewest problems, but we don't try to hide its deficiencies, and nothing suitable exists, it may be equivalent to time.time(). If the times you measure are too weird, measure again. For scheduling things a day or more in the future, you should use time.time() instead.

One issue that hasn't had enough attention: scope of a timer. If two processes running on the same machine ask for the time, do the values they see use the same epoch, or is the epoch dependent on the process? Some code I saw in timemodule.c for working around Windows clocks rolling over seem to imply that two processes may not always see the same timer value. Is there a use case where this matters?

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

More information about the Python-Dev mailing list