Python – time.time() vs. bash time

Question

I've been working on some Project Euler problems in Python 3 [osx 10.9], and I like to know how long they take to run.

I've been using the following two approaches to time my programs:

1)

import time
start = time.time()

[program]

print(time.time() - start)

2) On the bash command line, typing time python3 ./program.py

However, these two methods often give wildy different results. In the program I am working on now, the first returns 0.000263 (seconds, truncated) while the second gives

real    0m0.044s
user    0m0.032s
sys     0m0.009s

Clearly there is a huge discrepancy - two orders of magnitude compared to the real time.

My questions are:
a) Why the difference? Is it overhead from the interpreter?
b) Which one should I be using to accurately determine how long the program takes to run? Is time.time() accurate at such small intervals?

I realize these miniscule times are not of the utmost importance; this was more of a curiosity.

Thanks.

[UPDATE:]
Thank-you to all of the answers & comments. You were correct with the overhead. This program:

 import time
 start = time.time()

 print("hello world")

 print(time.time() - start)

takes ~0.045 sec, according to bash.

My complicated Project Euler problem took ~0.045 sec, according to bash. Problem solved.

I'll take a look at timeit. Thanks.

I would imagine it has to do with the order in which they are called. — kylieCatt, Jan 02 '14 at 21:58
A guess is Python spends most of its time loading the script and resolving imports. Only after that does your `time.time()` begin counting. Try using the `profile` class to run just your critical algorithm. Also see: http://stackoverflow.com/questions/582336/how-can-you-profile-a-python-script — Nate, Jan 02 '14 at 21:59

score 13 · Accepted Answer · answered Jan 02 '14 at 21:58

13

The interpreter imports site.py and can touch upon various other files on start-up. This all takes time before your import time line is ever executed:

$ touch empty.py
$ time python3 empty.py 

real    0m0.158s
user    0m0.033s
sys     0m0.021s

When timing code, take into account that other processes, disk flushes and hardware interrupts all take time too and influence your timings.

Use timeit.default_timer() to get the most accurate timer for your platform, but preferably use the timeit module itself to time individual snippets of code to eliminate as many variables as possible.

answered Jan 02 '14 at 21:58

Martijn Pieters

1,048,767
296
4,058
3,343

Whoa. 158 ms... That's amazing. – baum Jan 03 '14 at 01:36
I can rerun that and get half the time; it all depends what else the OS and hardware are doing. – Martijn Pieters Jan 03 '14 at 01:58

Iguananaut · Answer 2 · 2014-01-02T22:47:32.977

Because when you run the time builtin in bash the real time taken includes the time taken to start up the Python interpreter and import the required modules to run your code, rather than just timing the execution of a single function in your code.

To see this, try for example

import os
import time
start = time.time()
os.system('python <path_to_your_script>')
print time.time() - start

You'll find that this is much closer to what time reports.

Python – time.time() vs. bash time

2 Answers2