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

Guido van Rossum guido at python.org
Mon Apr 2 19:42:50 CEST 2012

You seem to have missed the episode where I explained that caching the
last value in order to avoid going backwards doesn't work -- at least
not if the cached value is internal to the API implementation.

2012/4/2 Kristján Valur Jónsson <kristjan at ccpgames.com>:
>> -----Original Message-----
>> From: python-dev-bounces+kristjan=ccpgames.com at python.org
>> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On
>> Behalf Of Cameron Simpson
>> Sent: 30. mars 2012 21:43
>> There seem to be a few competing features for clocks that people want:
>>   - monotonic - never going backward at all
>>   - high resolution
>>   - no steps
>  "no steps" is something unquantifiable.  All time has steps in it.  What you mean here is no 'noise'.  And this is also never actually achievable.
> A clock that ticks forwards, but sometimes stops some and then  ticks some more, is simply a clock with a lower resolution on average than what can be observed for certain time periods.
> It befuddles me somewhat how complicated you are making all of this.
> Simply provide the best high resolution, non-backwards ticking, performance timer that the platform provides, and don't try to make promises about unquantifiable things such as 'steps'.
> You can do this simply using QPC on windows and enforcing the forward ticking using a static local.
> Simply promise that this is a forward ticking clock with the highest resolution and lowest noise available for the platform and make no other guarantees, other than perhaps suggesting that this might not be used reliably for benchmarking on older os/hardware platforms.
> K

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

More information about the Python-Dev mailing list