-1

Why am I getting each time I execute the following program different times for t1_perf_time and t1_timeit_time? Why are the times not for every execution the same?

import numpy as np
import time
import timeit

t0_process_time = time.process_time()
t0_perf_time = time.perf_counter()
t0_timeit = timeit.default_timer()

x = np.array([[[1, 2],
               [3, 4]],
              
              [[5, 6],
               [7, 8]], 
              
              [[3, 1],
               [1, 5]]])

x_min = np.amin(x, axis=0)
print(x_min)

print("t1_process_time: ", time.process_time() - t0_process_time)
print("t1_perf_time: ", time.perf_counter() - t0_perf_time)
print("t1_timeit_time: ", timeit.default_timer() - t0_timeit)

The results are as follows:

  1. Execution of the program: t1_process_time: 0.0; t1_perf_time: 0.0008847999852150679; t1_timeit_time: 0.0009033000096678734

  2. Execution of the program: t1_process_time: 0.0; t1_perf_time: 0.0003133999998681247; t1_timeit_time: 0.0003309999592602253

  3. Execution of the program: t1_process_time: 0.0; t1_perf_time: 0.000278300023637712; t1_timeit_time: 0.0003150000120513141

MsX
  • 21
  • 1
  • 6

4 Answers4

3

The time deltas are small but since these are small numbers they look big. But I think the main problem is that you are mostly measuring how long it takes to print things and that includes calls to the system which will vary significantly per run. Moving the end time calls above the prints gives more consistent results.

import numpy as np
import time
import timeit

t0_process_time = time.process_time()
t0_perf_time = time.perf_counter()
t0_timeit = timeit.default_timer()

x = np.array([[[1, 2],
               [3, 4]],
              
              [[5, 6],
               [7, 8]], 
              
              [[3, 1],
               [1, 5]]])

x_min = np.amin(x, axis=0)


t1_process_time = time.process_time()
t1_perf_time =  time.perf_counter()
t1_timeit_time = timeit.default_timer()

#print(x_min)
print("----------")
print("t1_process_time: ", t1_process_time - t0_process_time)
print("t1_perf_time: ", t1_perf_time - t0_perf_time)
print("t1_timeit_time: ", t1_timeit_time - t0_timeit)

And several runs

~/tmp/aaa$ python3 test.py
----------
t1_process_time:  4.363200000001566e-05
t1_perf_time:  4.216799970890861e-05
t1_timeit_time:  4.1728000724106096e-05
~/tmp/aaa$ python3 test.py
----------
t1_process_time:  4.598000000000102e-05
t1_perf_time:  4.489000093599316e-05
t1_timeit_time:  4.4754000555258244e-05
~/tmp/aaa$ python3 test.py
----------
t1_process_time:  4.239400000000115e-05
t1_perf_time:  4.161900142207742e-05
t1_timeit_time:  4.158100091444794e-05
~/tmp/aaa$ python3 test.py
----------
t1_process_time:  4.783699999999502e-05
t1_perf_time:  4.641800114768557e-05
t1_timeit_time:  4.633000025933143e-05
~/tmp/aaa$ python3 test.py
----------
t1_process_time:  4.620399999999414e-05
t1_perf_time:  4.536599954008125e-05
t1_timeit_time:  4.5202999899629503e-05
~/tmp/aaa$ python3 test.py
----------
t1_process_time:  4.341699999999005e-05
t1_perf_time:  4.237100074533373e-05
t1_timeit_time:  4.228999932820443e-05
tdelaney
  • 73,364
  • 6
  • 83
  • 116
1

This may well depend on availability of system resources, especially the ones shared with other processes. Without having a complete snapshot of your system state, we can't really tell. However, this is why we don't measure individual runs of a program: there are too many confounding variables in the system. If you want a good profile of the run time, then use the repetition factor in timeit, and run the program from a script.

Prune
  • 76,765
  • 14
  • 60
  • 81
1

Because that's just how everything works: your pc will always be busy in a different way, now it's processing the browser, now it's checking for viruses, now the battery level is lower than it was before, etc, etc, causing the program to run at different speeds.

timeit is not to give you the exact processing time, as there is no such thing. Instead, it gives you the big picture as to how fast your code works, or to compare two different implementations on the same concept, so that you can choose the one that turns out fastest on most of the runs.

Red
  • 26,798
  • 7
  • 36
  • 58
1

Ultimately every operation the code in your program does can be reduced down into simpler Boolean operations performed by logic gates, which are implemented in hardware via combinations of electronic transistors below the microscopic scale in size. These transistors are where electric currents are manipulated to correspond to binary.

Although you may expect the mathematical operations of a computer to always take the same time to compute, in reality the mathematical operations rely on the less certain physical world where the properties of things like transistors lie within a given acceptable margin of error, as truly exact values are virtually impossible to engineer, due to things such as small impurities in metals and small variations in the dimensions cut. The properties of the electricity itself can also vary within an acceptable range. The transistors of a computer can also heat up and change or even be destroyed over time. Even phenomena such as quantum tunnelling of electrons and cosmic rays from space can affect your computer's performance in small ways.

The universe is inherently chaotic and so computers inherently are subject to that chaos. While computers are engineered to be affected as little as possible, they are still affected.

Alexander Kalian
  • 1,059
  • 2
  • 9
  • 17
  • I don't see how this has much effect over small time periods especially considering we are dealing discrete "time" increments fixed by system clock pulses. A logic gate may vary slightly it in its operation but it has a significant amount of time between pulses to settle. If variances between gates mattered like this, we could never get consistent operations. Measured "time" is really a counting of this clock. Bus contention on a memory cache miss would have a much greater effect. – tdelaney Dec 07 '20 at 22:30
  • Even just cosmic rays alone can cause serious computer glitches: https://science.howstuffworks.com/cosmic-rays-crash-electronics.htm – Alexander Kalian Dec 07 '20 at 22:37