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

[Guido van Rossum]

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)