[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Guido van Rossum]

On Sun, Apr 8, 2012 at 5:00 PM, Victor Stinner <victor.stinner at gmail.com> wrote:
>> IOW "What's good enough for sleep() is good enough for
>> user-implemented timeouts and scheduling." as a way to reach at least
>> one decision for a platform with agreed-upon cross-platform
>> characteristics that are useful.
>
> sleep() is implemented in the kernel. The kernel is notified when a
> clock is set, and so can choose how to handle time adjustement. Most
> "sleeping" functions use the system clock but don't care of clock
> adjustement.

We're going around in circles. I'm not asking what sleep does, I want
on principle a timer that does the same thing as sleep(), regardless
of how sleep() works. So if on some OS sleep() uses the same algorithm
as CLOCK_MONOTONIC_RAW, I want my timer to use that too. But if on
some other OS sleep() uses CLOCK_MONOTONIC, I want my timer there to
use that. And if on some OS sleep() is buggy and uses the time-of-day
clock, well, I wouldn't mind if my timer used the same thing.

>> I personally have a need for one potentially different clock -- to
>> measure short intervals for benchmarks and profiling. This might be
>> called time.performancetimer()?
>
> I deferred this topic because it is unclear to me if such timer has to
> count elapsed time during a sleep or not. For example, time.clock()
> does on UNIX, whereas it doesn't on Windows.

I will declare that that was a mistake in clock(), but one that's too
late to fix, because fixing it would break too many programs (those on
*nix that use it to measure CPU time, and those on Windows that use it
to measure real time).

>You may need two clocks
> for this:
>  * time.perf_counter(): high-resolution timer for benchmarking, count
> time elasped during a sleep
>  * time.process_time(): High-resolution (?) per-process timer from the
> CPU. (other possible names: time.process_cpu_time() or
> time.cpu_time())

TBH I don't need another timer that measures CPU time (not even on
Windows). In a sense, measuring CPU time is a relic from the age of
mainframes and timesharing, where CPU time was the most precious
resource (and in some cases the unit in which other resources were
expressed for accounting purposes). In modern days, it's much more
likely that the time you're measuring is somehow related to how long a
use has to wait for some result (e.g. web response times) and here
"wait time" is just as real as CPU time.

> On Windows, GetProcessTimes() has not a "high-resolution": it has a
> accuracy of 1 ms in the best case. QueryPerformanceCounter() counts
> time elapsed during a sleep, I don't know for GetProcessTimes.

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