[PYTHON] Is time.time () not very accurate?

Environment: python3.5.1 of win7 & blender 2.77a

When checking the time taken for processing

import time

start_time = time.time()

#
#Various processing
#

print(time.time() - start_time)

I often wrote: I often see it written like this. However, it was strange because the numbers often changed quite a bit each time I looked it up.

Accuracy of time.time ()

How accurate is it? I wrote in the timeit docs:

http://docs.python.jp/2/library/timeit.html#timeit.default_timer

On Windows, time.clock () has microsecond precision, while time.time () has only 1/60 second precision. On Unix, on the other hand, time.clock () is also 1/100 second accurate, and time.time () is more accurate.

It seems that Windows has only 1/60 second accuracy. You can't measure the time with this ...

Other functions that can measure time

Abolished in time.clock () 3.3 time.monotonic() time.perf_counter() time.process_time() It seems that this area is remarkable.

Use time.get_clock_info () to see the information.

import time

print("clock:\n{}".format(time.get_clock_info('clock')))
print("monotonic:\n{}".format(time.get_clock_info('monotonic')))
print("perf_counter:\n{}".format(time.get_clock_info('perf_counter')))
print("process_time:\n{}".format(time.get_clock_info('process_time')))
print("time:\n{}".format(time.get_clock_info('time')))

Output result

clock:
namespace(adjustable=False, implementation='QueryPerformanceCounter()',monotonic=True, resolution=6.984127871000365e-08)

monotonic:
namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015600099999999999)

perf_counter:
namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=6.984127871000365e-08)

process_time:
namespace(adjustable=False, implementation='GetProcessTimes()', monotonic=True, resolution=1e-07)

time:
namespace(adjustable=True, implementation='GetSystemTimeAsFileTime()', monotonic=False, resolution=0.015600099999999999)

Since resolution seems to be the number of seconds of clock resolution, it seems better to use the smaller valuetime.perf_counter ()ortime.process_time (). Looking at time.time (), it seems that the accuracy is only about 1/60 second.

Actual measurement

import time

start_time = time.perf_counter()
print("perf_counter = {:.7f}".format(time.perf_counter() - start_time))

start_time = time.process_time()
print("process_time = {:.7f}".format(time.process_time() - start_time))

Output result

perf_counter = 0.0000029
process_time = 0.0000000

time.perf_counter () seems to have the expected accuracy. time.process_time () is weird. Let's check the resolution of time.process_time ().

import time

time_list = []

time_list.append(time.process_time())
while len(time_list) < 5:
    next_time = time.process_time()
    if time_list[len(time_list)-1] != next_time:
        time_list.append(next_time)

print(time_list[1] - time_list[0])
print(time_list[2] - time_list[1])
print(time_list[3] - time_list[2])
print(time_list[4] - time_list[3])

Output result

0.015600100000000339
0.015600100000000339
0.015600100000000339
0.015600100000000339

Looking at this, it seems that time.process_time () has the same resolution as time.time ().

Conclusion

On Windows, the precision of time.time () is not very high, so if you want precision, use time.perf_counter ().

Recommended Posts

Is time.time () not very accurate?
Python round is not strictly round
TypeError:'int' object is not subscriptable
Python list is not a list
NameError: name'__file__' is not defined
Command is not found in sudo
[Django error]'RenameAttributes' object is not iterable
Multiplicative hash is not perfect (proven)
Sympy Laplace transform is not practical