Python - time.clock() vs. time.time() - accuracy?

Question

Which is better to use for timing in Python? time.clock() or time.time()? Which one provides more accuracy?

for example:

start = time.clock()
... do something
elapsed = (time.clock() - start)

vs.

start = time.time()
... do something
elapsed = (time.time() - start)

Answer 1

Depends on what you care about. If you mean WALL TIME (as in, the time on the clock on your wall), time.clock() provides NO accuracy because it may manage CPU time.

Answer 2

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.

time() -> floating point number

Return the current time in seconds since the Epoch.
Fractions of a second may be present if the system clock provides them.

Usually time() is more precise, because operating systems do not store the process running time with the precision they store the system time (ie, actual time)

Answer 3

The short answer is: most of the time time.clock() will be better. However, if you're timing some hardware (for example some algorithm you put in the GPU), then time.clock() will get rid of this time and time.time() is the only solution left.

Note: whatever the method used, the timing will depend on factors you cannot control (when will the process switch, how often, ...), this is worse with time.time() but exists also with time.clock(), so you should never run one timing test only, but always run a series of test and look at mean/variance of the times.

Answer 4

Under unix, time.clock() measures CPU time used by the current process. os.system() will consume almost zero CPU while it waits for the command you ran to finish.

You probably want time.time(), eg

  >>> from time import clock, time
  >>> print clock(), time()
  0.01 1169573460.96
  >>> print clock(), time()
  0.01 1169573463.76
  >>> print clock(), time()
  0.01 1169573467.09
  >>> 

However running the same under windows you get a quite different result :-

  >>> from time import clock, time
  >>> print clock(), time()
  7.54285810068e-006 1169574534.84
  >>> print clock(), time()
  3.32073322168 1169574538.16
  >>> print clock(), time()
  7.32428004118 1169574542.15
  >>>

In windows clock() counts in real time and at much higher resolution than time().

Under windows time() counts in 1ms steps wheras it usually counts in 1us steps under linux.

source: http://mail.python.org/pipermail/python-list/2007-January/423575.html

Third in Google's results to your question.

Answer 5

Short answer: use time.clock() for timing in Python.

On *nix systems, clock() returns the processor time as a floating point number, expressed in seconds. On Windows, it returns the seconds elapsed since the first call to this function, as a floating point number.

time() returns the the seconds since the epoch, in UTC, as a floating point number. There is no guarantee that you will get a better precision that 1 second (even though time() returns a floating point number). Also note that if the system clock has been set back between two calls to this function, the second function call will return a lower value.

Answer 6

According to the time module docs:

clock()

On Unix, return the current processor time as a floating point number expressed in seconds. The precision, and in fact the very definition of the meaning of ``processor time'', depends on that of the C function of the same name, but in any case, this is the function to use for benchmarking Python or timing algorithms.

Additionally, there is the timeit module for benchmarking code snippets.

Answer 7

Others have answered re: time.time() vs. time.clock().

However, if you're timing the execution of a block of code for benchmarking/profiling purposes, you should take a look at the timeit module.

Answer 8

On Unix time.clock() measures the amount of CPU time that has been used by the current process, so it's no good for measuring elapsed time from some point in the past. On Windows it will measure wall-clock seconds elapsed since the first call to the function. On either system time.time() will return seconds passed since the epoch.

If you're writing code that's meant only for Windows, either will work (though you'll use the two differently - no subtraction is necessary for time.clock()). If this is going to run on a Unix system or you want code that is guaranteed to be portable, you will want to use time.time().

Answer 9

The difference is very platform-specific.

clock() is very different on Windows than on Linux, for example.

For the sort of examples you describe, you probably want the "timeit" module instead.

Answer 10

To the best of my understanding, time.clock() has as much precision as your system will allow it.

Answer 11

It looks like you're trying to time your own code and not using this in a production release. For this kind of situation, it's almost always better to use someone else's timing mechanism. For python, that's timeit:

import timeit

#Save the code you want to test beforehand and import it in timeit
timer = timeit.Timer("mymodule.myfunc('input')", "import mymodule")

#You want the fastest time, not the average.
#Your system will theoretically execute code at the same rate each time
#It doesn't because of other processes,
#so get the run with the least interference
print min(timer.repeat())

This will run your code 1,000,000 times, 3 times, and print the minimum value, all while using an accurate timing mechanism. Pretty cool, huh? You can also specify lower or higher runs and repeats:

print min(timer.repeat(repeat=5, number=2000000))
print min(timer.repeat(repeat=3, number=1000))

If you want to see what specifically needs speeding up, try profile or cProfile (cProfile being less tested because it's newer, but theoretically better.)

Cheers!

Answer 12

One thing to keep in mind: Changing the system time affects time.time() but not time.clock().

I needed to control some automatic tests executions. If one step of the test case took more than a given amount of time, that TC was aborted to go on with the next one.

But sometimes a step needed to change the system time (to check the scheduler module of the application under test), so after setting the system time a few hours in the future, the TC timeout expired and the test case was aborted. I had to switch from time.time() to time.clock() to handle this properly.