time.clock() or time.time()

Discussion in 'Python' started by peterbe@gmail.com, Aug 2, 2005.

  1. Guest

    What's the difference between time.clock() and time.time()
    (and please don't say clock() is the CPU clock and time() is the actual
    time because that doesn't help me at all :)

    I'm trying to benchmark some function calls for Zope project and when I
    use t0=time.clock(); foo(); print time.clock()-t0
    I get much smaller values than when I use time.clock() (most of them
    0.0 but some 0.01)
    When I use time.time() I get values like 0.0133562088013,
    0.00669002532959 etc.
    To me it looks like time.time() gives a better measure (at least from a
    statistical practical point of view).
    , Aug 2, 2005
    #1
    1. Advertising

  2. wrote:
    > What's the difference between time.clock() and time.time()
    > (and please don't say clock() is the CPU clock and time() is the actual
    > time because that doesn't help me at all :)
    >
    > I'm trying to benchmark some function calls for Zope project and when I
    > use t0=time.clock(); foo(); print time.clock()-t0
    > I get much smaller values than when I use time.clock() (most of them
    > 0.0 but some 0.01)
    > When I use time.time() I get values like 0.0133562088013,
    > 0.00669002532959 etc.
    > To me it looks like time.time() gives a better measure (at least from a
    > statistical practical point of view).


    time.time() is very likely what you want.

    time.time() measures real time, while time.clock() measures the time the
    CPU dedicates to your program. For example, if your function spends 2
    seconds doing pure I/O and 3 seconds doing pure computation, you should
    expect time.time() to show 5 that seconds elapsed, and time.clock() to
    show that the CPU was consumed by your program for 3 seconds.

    Shane
    Shane Hathaway, Aug 2, 2005
    #2
    1. Advertising

  3. schrieb:
    > What's the difference between time.clock() and time.time()
    > (and please don't say clock() is the CPU clock and time() is the actual
    > time because that doesn't help me at all :)


    clock (depending on the platform ?) measures the time spent by your program.

    Time gives you the system time, so the difference is the time between
    your calls, your program could have been idle (waiting for input or
    sharing processor due to multitasking)

    > I'm trying to benchmark some function calls for Zope project and when I
    > use t0=time.clock(); foo(); print time.clock()-t0
    > I get much smaller values than when I use time.clock() (most of them
    > 0.0 but some 0.01)


    Run your code 100 times and divide the result by 100.

    Leonhard
    Leonhard Vogt, Aug 2, 2005
    #3
  4. Magnus Lycka Guest

    Shane Hathaway wrote:
    > time.time() measures real time, while time.clock() measures the time the
    > CPU dedicates to your program.


    I suppose that varies with the platform... "help(time.clock)" says:

    Help on built-in function clock:

    clock(...)
    clock() -> floating point number

    Return the CPU time or real time since the start of the process or
    since
    the first call to clock(). This has as much precision as the
    system records.

    Another thing to notice is that depending on OS, either time.time() or
    time.clock() might have much higher precision than the other.

    For Linux on Intel at least, you'll probably want to always use
    time.time(). On Windows, you're likely to prefer time.clock(), to
    measure relative times, since time.time() will have too low resolution
    for measuring short thingies. Be aware that time.clock() will restart
    at 0 now and then though. I.e. t1=time.clock();f();t2=time.clock() will
    have t1>t2 now and then. Using time.time(), that won't happen until
    after I retire... :)

    For Linux, see "man 2 time" and "man 3 clock".
    Magnus Lycka, Aug 2, 2005
    #4
  5. Peter Hansen Guest

    Magnus Lycka wrote:
    > On Windows, you're likely to prefer time.clock(), to
    > measure relative times, since time.time() will have too low resolution
    > for measuring short thingies.


    Specifically, using the NT/XP family of Windows operating systems
    time.time() has a resolution of approximately 0.015 seconds (I believe
    it might be exactly 1/64 second, but it should be easy to confirm with a
    google search).
    Peter Hansen, Aug 2, 2005
    #5
  6. Magnus Lycka wrote:
    > Shane Hathaway wrote:
    >
    >>time.time() measures real time, while time.clock() measures the time the
    >>CPU dedicates to your program.

    >
    >
    > I suppose that varies with the platform... "help(time.clock)" says:
    >
    > Help on built-in function clock:
    >
    > clock(...)
    > clock() -> floating point number
    >
    > Return the CPU time or real time since the start of the process or
    > since
    > the first call to clock(). This has as much precision as the
    > system records.
    >
    > Another thing to notice is that depending on OS, either time.time() or
    > time.clock() might have much higher precision than the other.


    I didn't notice that. Thanks.

    However, isn't this thoroughly un-Pythonic? No wonder people have to
    ask. Wouldn't it be better to have:

    time.time() -> real time, with as much precision as the platform
    provides. Does not wrap around.

    time.cputime() -> CPU time, or real time on platforms that don't
    measure CPU time separately from real time. May wrap around in
    long-running processes.

    Shane
    Shane Hathaway, Aug 3, 2005
    #6
  7. Nelson Minar Guest

    "" <> writes:
    > I'm trying to benchmark some function calls for Zope project


    Other folks have explained time() vs. clock(), so I'll leave that.

    But rather than roll your own timer functions, consider using timeit.
    Nelson Minar, Aug 3, 2005
    #7
  8. On Wed, 03 Aug 2005 04:11:36 -0600, Shane Hathaway
    <> declaimed the following in comp.lang.python:


    > However, isn't this thoroughly un-Pythonic? No wonder people have to
    > ask. Wouldn't it be better to have:
    >

    The problem is that these are just bindings to the C (for the
    CPython) runtime library -- and that is outside of Python control.

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
    Dennis Lee Bieber, Aug 4, 2005
    #8
  9. Magnus Lycka Guest

    Shane Hathaway wrote:
    > However, isn't this thoroughly un-Pythonic? No wonder people have to
    > ask.


    Only if they've never read K&R, and I thought that was compulsory! ;^)

    There are a few python libraries, such as time and math, that are
    basically just thin wrappers around standard C libraries. In some
    cases, they are complemented with more modern libraries, such as
    datetime.

    You might argue on how pythonic (or useful, or beginner friendly)
    they are, but they cost very little to maintain across platforms.
    It's important to keep the maintenance costs down for any project,
    certainly for a project such as Python, and as far as I know, there
    is no cross platform standard API to access CPU time, so a
    time.cputime() function would require a lot of work to maintain,
    and I don't know if anyone really had a strong need for it.

    There is a benefit to maintain (standard or not) API's that
    programmers have experience from when programming in other languages.
    Of course, I think it's a good thing to properly adapt API's to Python
    ways of working. I.e. if a C++ library returning an iterator is wrapped,
    I want to be able to do...

    for item in container:
    print item

    ....rather than...

    it = container.start()
    while it != container.end():
    item = it.deref()
    print item

    Still, it's often a Good Thing if a Python API is as similar as
    possible to e.g. a C++ API that it wraps.

    One of the great aspects of Python is that it's a good team player.
    It doesn't try to create a world of its own, like Smalltalk and
    ABC does, but blends in well in a mixed language environment.

    We work extensively with a mix of C++ and Python (as well as some
    other languages) here at Carmen, and it would be painful if I had
    to remember two different API's for each library that I access from
    both C++ and Python.
    Magnus Lycka, Aug 5, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Valentin Tihomirov

    Are clock and divided clock synchronous?

    Valentin Tihomirov, Oct 23, 2003, in forum: VHDL
    Replies:
    11
    Views:
    3,275
    louis lin
    Oct 28, 2003
  2. Replies:
    4
    Views:
    710
    Peter Alfke
    Apr 27, 2006
  3. Replies:
    5
    Views:
    2,150
    Ricardo
    Jun 23, 2006
  4. himassk
    Replies:
    1
    Views:
    1,226
    Paul Uiterlinden
    May 16, 2007
  5. pankaj.goel
    Replies:
    6
    Views:
    930
    pankaj.goel
    Nov 25, 2008
Loading...

Share This Page