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

Victor Stinner victor.stinner at gmail.com
Tue Apr 3 13:42:51 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.

Yes, and I can't find it by briefly searching my mail.  I haven't had the energy to follow every bit of this discussion because it has become completely insane.

I'm trying to complete the PEP, but I didn't add this part yet.

Of course we cannot promise not moving backwards, since there is a 64 bit wraparound some years in the future.

Some years? I computed 584.5 years, so it should not occur in practice. 32-bit wraparound is a common issue which occurs in practice on Windows (49.7 days wraparound), and I propose a workaround in the PEP (already implemented in the related issue).

Here's actual code from production:

BOOL WINAPI QueryPerformanceCounterCCP( LARGEINTEGER* li ) {  static LARGEINTEGER last = {0};  BOOL ok = QueryPerformanceCounter(li);  if( !ok )  {  return FALSE;  }

Did you already see it failing in practice? Python ignores the return value and only uses the counter value.

Even negative delta values of time are usually  harmless on the application level.  A curiosity, but harmless.

It depends on your usecase. For a scheduler or to implement a timeout, it does matter. For a benchmark, it's not an issue because you usually repeat a test at least 3 times. Most advanced benchmarked tools gives a confidence factor to check if the benchmark ran fine or not.

 I am offering empirical evidence here from hundreds of thousands of computers over six years: For timing and benchmarking, QPC is good enough, and will only be as precise as the hardware and operating system permits, which in practice is good enough.

The PEP contains also different proofs that QPC is not steady, especially on virtual machines.

Victor

More information about the Python-Dev mailing list