Python Clocks Explained

As of Python 3.3, there are five different types of clocks in the time module, one of which is deprecated:

1. time.clock() deprecated in 3.3
2. time.monotonic()
3. time.perf_counter()
4. time.process_time()
5. time.time()

I’ve been trying to figure out what different uses each of the clock types has.

Using time.get_clock_info(name), I got the following information about each clock (lowest to highest resolution):

Some Definitions

• Adjustable – The clock can be changed by the system administrator. This is important because an adjustable clock is unreliable when calculating time deltas. So time should not be used to calculate time deltas.
• Monotonic – Monotonic clocks are unidirectional. They can only go forward. This means that they are only useful in giving you relative times – the times between two events.
• Resolution – The time between clock ticks. The smaller the number, the greater number of ticks per time unit. So, a high resolution clock has a very small resolution number.
• Tick Rate – The number of ticks per second. This is the inverse of Resolution. A high resolution clock has a high tick rate.

So, based on the information above, we know this:

• time.clock() should NOT be used as of Python 3.3. It’s deprecated.
• time.time() should NOT be used for comparing relative times. It’s not reliable because it’s adjustable.

That leaves us with time.monotonic(), time.perf_counter(), and time.process_time() for comparing relative times. But when should you use which? Some thoughts:

• time.monotonic() has by far the slowest tick rate. So, using time.perf_counter() or time.process_time() would always give you more precise results.
• time.process_time() has a tick rate that is about 4.67 times faster than time.perf_counter(), which has a tick rate that is about 33,491 times faster than time.monotonic().
• According to the doc, time.process_time() returns “the sum of the system and user CPU time of the current process.” It only counts time spent on the process in question. I think this means that its results will not vary based on how busy the computer is running unrelated processes.

The code below checks how many times each of these three clocks changes in a loop that iterates 1,000,000 times. Before looking at the results, what would you expect them to be?

I expected that:

• time.process_time() would change about 4.67 times more often than time.perf_counter().
• time.perf_counter() would change about 33,491 times more often than time.monotonic().

changes=[]
t, num = 0, 0
for i in range(1000000):
    t_new = time.process_time()
    if t_new != t:
        num += 1
    t = t_new
changes.append( ('process_time()', num) )
    
t, num = 0, 0
for i in range(1000000):
    t_new = time.perf_counter()
    if t_new != t:
        num += 1
    t = t_new
changes.append( ('perf_counter()', num) )
t, num = 0, 0
for i in range(1000000):
    t_new = time.monotonic()
    if t_new != t:
        num += 1
    t = t_new
changes.append( ('monotonic()', num) )
changes.sort(key=lambda c:c[1], reverse=True)
for i, c in enumerate(changes, 1):
    print(i, '.
', c[0], ': ', c[1], sep='')

Here are the number of changes for each:

time.perf_counter() changes 38,537 times more often than time.monotonic(). That’s not too far from the 33,491 that I expected.

But what’s going on with time.process_time()? It has the highest resolution, but it only changes 22 times in 1,000,000 iterations. That indicates that it can loop through 45,454 iterations without a measurable time change. That doesn’t make sense to me.

Also, the third column shows the amount of time (as a fraction of a second) that it takes for each loop to complete. The only difference between the three loops is the type of clock used and the resulting number of times the num variable needs to be changed. Considering that num is changed half a million times in the perf_counter loop, I would guess that time.perf_counter() and time.monotonic(). I checked that assumption by just checking the clock on each iteration:

changes=[]
t, num, t_orig = 0, 0, time.process_time()
for i in range(1000000):
    t = time.process_time()
changes.append( ('process_time()2', num, t - t_orig) )
t, num, t_orig = 0, 0, time.perf_counter()
for i in range(1000000):
    t = time.perf_counter()
changes.append( ('perf_counter()', num, t - t_orig) )
t, num, t_orig = 0, 0, time.monotonic()
for i in range(1000000):
    t = time.monotonic()
changes.append( ('monotonic()', num, t - t_orig) )
changes.sort(key=lambda c:c[1], reverse=True)
for i, c in enumerate(changes, 1):
    print(i, '.
', c[0], ': ', c[1], ', ', c[2], sep='')

The results:

• time.monotonic() is slightly less time consuming than time.perf_counter().
• Both time.monotonic() and time.perf_counter() consume less than half the time as time.process_time().

What does all this mean?

I’m not sure really. But, I think:

time.perf_counter() is the most useful

time.perf_counter() will give you the most accurate results when testing the difference between two times. And time.perf_counter() doesn’t appear to be significantly more expensive than time.monotonic(). So, at this point, if I needed super accurate time deltas, I would use time.perf_counter(). For me this is all academic as I always use timeit for this sort of thing. Incidentally, timeit uses time.perf_counter()by default.

When to use time.process_time()

According to PEP 0418, the profile module, which provides stats on how long different parts of a program took to run, uses time.process_time(). Unless you’re writing your own profile module, I don’t see a need for time.process_time().

When to use time.monotonic()

Again, according to the PEP 0418, several modules use (or could use) time.monotonic(), including concurrent.futures, multiprocessing, queue, subprocess, telnet and threading modules to implement timeout. I’m not sure why they do though. It seems to me that time.perf_counter() is just as fast and more accurate.

By the way, different operating systems can use different underlying C functions for the different types of clocks. I’m using Windows 64-bit, which uses the following implementations: