time.clock() or time.time()

[peterbe]

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

 

[Shane Hathaway]

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

 

[Leonhard Vogt]

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

 

[Magnus Lycka]

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

 

[Peter Hansen]

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

 

[Shane Hathaway]

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

 

[Nelson Minar]

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.

 

[Dennis Lee Bieber]

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.

--

 

[Magnus Lycka]

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.