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

[Guido van Rossum]

On Mon, Apr 2, 2012 at 2:31 AM, Sam Partington <sam.partington at gmail.com> wrote:
> On 30 March 2012 21:52, Guido van Rossum <guido at python.org> wrote:
>> Oh dear. I really want to say that 15 ms is good enough. Some possible
>> exceptions I can think of:
>>
>> - Profiling. But this really wants to measure CPU time anyways, and it
>> already uses a variety of hacks and heuristics to pick the best timer,
>> so I don't really care.
>
> That depends on what you're profiling.  If you're profiling CPU bound
> algorithms then yes CPU time is better. But if your trying to
> profile/measure hardware device/comms performance for example then CPU
> time is of no interest.  There, on windows the 15ms resolution of
> time.time makes it useless.  For some reason I always forget this and
> sit looking at trace outs for 5 minutes wondering why everything takes
> either 0, 15, or 30ms.
>
> For nearly all my use cases I'm not terribly interested in
> monotonicity, or stability in suspend/resume states so I won't give my
> opinions on thiose (though I can see they are good things and can well
> imagine needing them one day), I just want an easy way of getting at
> least micro second resolution cross platform.
>
> I don't mind particularly what you call it but FWIW 'highres' seems a
> bit odd to me.  It seems that highres is likely to seem lowres one
> day, and then you need to add higherres() and then
> evenhigherthanthatres().
>
> I would go with microtime(), or nanotime()  it doesn't make any
> promises about anything other than the resolution.

You're being altogether too reasonable about it. :-) People keep
asking for a clock that has nanosecond precision and yet will tell
time accurately for centuries, without ever skipping forward or
backward...

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