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

[Kristján Valur Jónsson]

> -----Original Message-----
> From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On Behalf
> Of Guido van Rossum
> Sent: 2. apríl 2012 17:43
> To: Kristján Valur Jónsson
> Cc: Cameron Simpson; Python Dev
> Subject: Re: [Python-Dev] Use QueryPerformanceCounter() for
> time.monotonic() and/or time.highres()?
> 
> 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.

Of course we cannot promise not moving backwards, since there is a 64 bit wraparound some years in the future.  Otherwise, evidence contradicts your claim.
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;
	}

	if( li->QuadPart > last.QuadPart )
	{
		last = *li;
	}
	else
	{
		*li = last;
	}
	return TRUE;
}

This has been running for many years on an incredible array of hardware and operating systems.  However, we mostly don't do this caching anymore, this code is a rudiment.  In all other places, a straight QPC is good enough for our purposes.  Even negative delta values of time are usually  harmless on the application level.  A curiosity, but harmless.  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.

Which is why am flabbergasted by all of this bikeshedding.  My original submission (http://bugs.python.org/issue10278) Is merely a suggestion to provide a standardised clock function, useful for measuring the delta-t to the best abilities of the platform.  This is incredibly useful in many areas and necessary because time.clock() currently means different things on different operating systems.
There is no need to try to overspecify this to become something which it never can be.  If someone wants a real time clock with no time slew to control a radio telescope, he better write his own interface to an atomic clock.  What he definitely shouldn't be doing is using a built in timer on an old computer with an old operating system.

Also, since you objected to the original suggestion of time.wallclock(), here is the definition from Wikipedia:  http://en.wikipedia.org/wiki/Wall_clock_time . I actually never read this before, but it agrees with my original definition of relative passage of time in the real world.  I got the term myself from using profiling tools, which measure program execution in cpu time or wallclock time.

Cheers,
Kristján