guido at python
Mar 14, 2012, 9:22 AM
Post #23 of 67
I have a totally different observation. Presumably the primary use
Re: Drop the new time.wallclock() function?
[In reply to]
case for these timers is to measure real time intervals for the
purpose of profiling various operations. For this purpose we want them
to be as "steady" as possible: tick at a constant rate, don't jump
forward or backward. (And they shouldn't invoke the concept of "CPU"
time -- we already have time.clock() for that, besides it's often
wrong, e.g. you might be measuring some sort of I/O performance.) If
this means that a second as measured by time.time() is sometimes not
the same as a second measured by this timer (due to time.time()
occasionally jumping due to clock adjustments), that's fine with me.
If this means it's unreliable inside a VM, well, it seems that's a
property of the underlying OS timer, and there's not much we can do
about it except letting a knowledgeable user override the timer user.
As for names, I like Jeffrey's idea of having "steady" in the name.
On Wed, Mar 14, 2012 at 9:11 AM, Matt Joiner <anacrolix [at] gmail> wrote:
> I have some observations regarding this:
> Victor's existing time.monotonic and time.wallclock make use of
> QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of
> these are hardware-based counters, their monotonicity is just a
> convenient property of the timer sources. Furthermore, time values can
> actually vary depending on the processor the call is served on.
> time.hardware()? time.monotonic_raw()?
> There are bug reports on Linux that CLOCK_MONOTONIC isn't always
> monotonic. This is why CLOCK_MONOTONIC_RAW was created. There's also
> the issue of time leaps (forward), which also isn't a problem with the
> latter form. time.monotonic(raw_only=False)?
> The real value of "monotonic" timers is that they don't leap
> backwards, and preferably don't leap forwards. Whether they are
> absolute is of no consequence. I would suggest that the API reflect
> this, and that more specific time values be obtained using the proper
> raw syscall wrapper (like time.clock_gettime) if required.
> The ultimate use of the function name being established is for use in
> timeouts and relative timings.
> Where an option is present, it disallows fallbacks like
> CLOCK_MONOTONIC and other weaker forms:
> †* time.hardware(fallback=True) -> reflects the source of the timing
> impeccably. alerts users to possible affinity issues
> †* time.monotonic_raw() -> a bit linux specific...
> †* time.relative(strict=False) -> matches the use case. a warning
> could be put regarding hardware timings
> †* time.monotonic(raw_only=False) -> closest to the existing
> implementation. the keyword name i think is better.
--Guido van Rossum (python.org/~guido)
Python-Dev mailing list
Python-Dev [at] python