timeit module

>>> import timeit
>>> t = timeit.Timer("soundex1a.soundex('Pilgrim')", "import soundex1a")
>>> t.timeit()
10.787981033325195
>>> t.repeat()
[10.59093189239502, 10.520797967910767, 10.513777017593384]
>>> t.repeat(3, 2000000)
[22.054033041000366, 21.18790602684021, 21.265258073806763]
>>> t.repeat(5, 2000000)
[21.35662817955017, 21.061805963516235, 21.77834391593933, 22.74197006225586, 22.04066300392151]

The timeit module defines one class, Timer, which takes two arguments. Both arguments are
strings. The first argument is the statement you wish to time; in this case, you are timing a call to the
Soundex function within the soundex with an argument of 'Pilgrim'. The second argument to the
Timer class is the import statement that sets up the environment for the statement. Internally, timeit
sets up an isolated virtual environment, manually executes the setup statement (importing the soundex
module), then manually compiles and executes the timed statement (calling the Soundex function).

Once you have the Timer object, the easiest thing to do is call timeit(), which calls your function 1
million times and returns the number of seconds it took to do it.

The other major method of the Timer object is repeat(), which takes two optional arguments. The
first argument is the number of times to repeat the entire test, and the second argument is the number of
times to call the timed statement within each test. Both arguments are optional, and they default to 3 and
1000000 respectively. The repeat() method returns a list of the times each test cycle took, in
seconds.

You can use the timeit module on the command line to test an existing Python program, without modifying the
code. See http://docs.python.org/lib/node396.html for documentation on the command−line flags.
Note that repeat() returns a list of times. The times will almost never be identical, due to slight variations in how
much processor time the Python interpreter is getting (and those pesky background processes that you can't get rid of).
Your first thought might be to say "Let's take the average and call that The True Number."

In fact, that's almost certainly wrong. The tests that took longer didn't take longer because of variations in your code or
in the Python interpreter; they took longer because of those pesky background processes, or other factors outside of
the Python interpreter that you can't fully eliminate. If the different timing results differ by more than a few percent,
you still have too much variability to trust the results. Otherwise, take the minimum time and discard the rest.
Python has a handy min function that takes a list and returns the smallest value:
 
>>> min(t.repeat(3, 1000000))
8.22203948912
 
The timeit module only works if you already know what piece of code you need to optimize. If you have a larger
Python program and don't know where your performance problems are, check out the hotshot module.
(http://docs.python.org/lib/module−hotshot.html)