Home Original page

[Python-Dev] Drop the new time.wallclock() function?

Matt Joiner anacrolix at gmail.com
Wed Mar 14 18:08:39 CET 2012 
On Thu, Mar 15, 2012 at 12:22 AM, Guido van Rossum <guido at python.org> wrote:
> I have a totally different observation. Presumably the primary use
> 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.

In that case I'd suggest either time.hardware(strict=True), or
time.steady(strict=True), since the only timers exposed natively that
are both high resolution and steady are on the hardware. A warning
about CPU affinity is also still wise methinks.
More information about the Python-Dev mailing list