[Python-Dev] time.clock() on windows

M.-A. Lemburg 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
> changed.
> 
> Of course, there are no doubt people relying on the broken behavior...

I'm not sure I understand why time.clock() should be considered
broken.

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:

	Tools/pybench/systimes.py

This module tries to provide a cross-platform API for
process and system time:

""" systimes() user and system timer implementations for use by
    pybench.

    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
    platforms.

    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:

    def systimes():

        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.

"""

-- 
Marc-Andre Lemburg
eGenix.com

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
               http://www.egenix.com/company/contact/


More information about the Python-Dev mailing list