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

[Victor Stinner]

>> 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( LARGE_INTEGER* li )
> {
>        static LARGE_INTEGER 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