[Python-Dev] time.clock() on windows
mal at egenix.com
Thu Oct 22 12:57:32 CEST 2009
Curt Hagenlocher wrote:
> On Wed, Oct 21, 2009 at 1:51 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Kristján Valur Jónsson <kristjan <at> ccpgames.com> writes:
>>> You are right, on windows time.clock() is based relative to its first call
>>> in the process. There is no such promise made on unix.
>>> QueryPerformanceCounter() (what time.clock uses()) is a robust high
>>> resolution timer that is processor/core independent. It should be
>>> possible to use it across different processes too, if this
>>> annoying rebasing wasn't there.
>> Well, could we simply have a high-resolution time.time()?
>> Or is Windows just too limited to provide this?
> Presumably you could fake something like this by combining output from
> an initial time(), an initial QueryPerformanceCounter() and the
> current QueryPerformanceCounter(). But it makes more sense to
> understand why someone chose to implement time.clock() on Windows the
> way they did -- this seems very broken to me, and I think it should be
> Of course, there are no doubt people relying on the broken behavior...
I'm not sure I understand why time.clock() should be considered
time.clock() is used for measuring process CPU time and is usually
only used in a relative way, ie. you remember that start value,
do something, then subtract the end value from the start value.
For absolute CPU time values associated with a process, it's usually
better to rely on other APIs such as getrusage() on Unix.
You might want to have a look at the systimes module that
comes with pybench for some alternative timers:
This module tries to provide a cross-platform API for
process and system time:
""" systimes() user and system timer implementations for use by
This module implements various different strategies for measuring
performance timings. It tries to choose the best available method
based on the platforma and available tools.
On Windows, it is recommended to have the Mark Hammond win32
package installed. Alternatively, the Thomas Heller ctypes
packages can also be used.
On Unix systems, the standard resource module provides the highest
resolution timings. Unfortunately, it is not available on all Unix
If no supported timing methods based on process time can be found,
the module reverts to the highest resolution wall-clock timer
instead. The system time part will then always be 0.0.
The module exports one public API:
Return the current timer values for measuring user and system
time as tuple of seconds (user_time, system_time).
Copyright (c) 2006, Marc-Andre Lemburg (mal at egenix.com). See the
documentation for further information on copyrights, or contact
the author. All Rights Reserved.
Professional Python Services directly from the Source (#1, Oct 22 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the Python-Dev