Python Performance
Parity Testing
from timeit import Timer
t1 = Timer("for i in xrange(100): i % 2")
t2 = Timer("for i in xrange(100): i & 1")
# The "not" tests show what happens when interpreting
# the result as a boolean
t3 = Timer("for i in xrange(100): not i % 2")
t4 = Timer("for i in xrange(100): not i & 1")
print "Checking for odd parity with `mod`:\t%.4f" % t1.timeit()
print "Checking for odd parity with `and`:\t%.4f" % t2.timeit()
print "Checking for even parity with `mod`:\t%.4f" % t3.timeit()
print "Checking for even parity with `and`:\t%.4f" % t4.timeit()
MacPython 2.7.2
Checking for odd parity with `mod`: 6.5617
Checking for odd parity with `and`: 5.3778
Checking for even parity with `mod`: 8.4417
Checking for even parity with `and`: 7.4086
PyPy 1.6.0 (with GCC 4.0.1; Python 2.7.2)
Checking for odd parity with `mod`: 0.2556
Checking for odd parity with `and`: 0.2312
Checking for even parity with `mod`: 1.7576
Checking for even parity with `and`: 0.6614
The results for odd parity were murky. Sometimes mod was slightly faster; sometimes bitwise-and was faster. There was no question with the even parity, however: The bitwise-and operator played much more nicely with the `not` operator than did the mod operator.
Jython 2.5.2
Checking for odd parity with `mod`: 3.4480
Checking for odd parity with `and`: 1.9380
Checking for even parity with `mod`: 3.6050
Checking for even parity with `and`: 2.0440
Tuple Unpacking
from timeit import Timer
index1 = Timer("x = tpl[0]", "tpl = (5,)")
unpack1 = Timer("x, = tpl", "tpl = (5,)")
index2 = Timer("x = tpl[1]", "tpl = (5, 6)")
unpack2 = Timer("y, x = tpl", "tpl = (5, 6)")
index3 = Timer("x = tpl[2]", "tpl = (5, 6, 7)")
unpack3 = Timer("y, y, x = tpl", "tpl = (5, 6, 7)")
index4 = Timer("x = tpl[3]", "tpl = (5, 6, 7, 8)")
unpack4 = Timer("y, y, y, x = tpl", "tpl = (5, 6, 7, 8)")
list_index2 = Timer("[tpl[1] for tpl in tuples]", "tuples = [(i, i * i) for i in xrange(100)]")
list_unpack2 = Timer("[y for x, y in tuples]", "tuples = [(i, i * i) for i in xrange(100)]")
list_map2 = Timer("map(itemgetter(1), tuples)", "tuples = [(i, i * i) for i in xrange(100)]; from operator import itemgetter")
times = 100000000
print "Indexing vs. unpacking a 1-tuple:\t%.4f\t%.4f" % (index1.timeit(number=times), unpack1.timeit(number=times))
print "Indexing vs. unpacking a 2-tuple:\t%.4f\t%.4f" % (index2.timeit(number=times), unpack2.timeit(number=times))
print "Indexing vs. unpacking a 3-tuple:\t%.4f\t%.4f" % (index3.timeit(number=times), unpack3.timeit(number=times))
print "Indexing vs. unpacking a 4-tuple:\t%.4f\t%.4f" % (index4.timeit(number=times), unpack4.timeit(number=times))
print "Indexing vs. unpacking a list of 2-tuples:\t%.4f\t%.4f" % (list_index2.timeit(), list_unpack2.timeit())
print "map() and itemgetter() (just for kicks):\t%.4f" % (list_map2.timeit())
MacPython 2.7.2
Indexing vs. unpacking a 1-tuple: 5.0712 3.3939
Indexing vs. unpacking a 2-tuple: 5.7888 6.2801
Indexing vs. unpacking a 3-tuple: 6.1820 7.5976
Indexing vs. unpacking a 4-tuple: 7.1802 7.8219
Indexing vs. unpacking a list of 2-tuples: 8.6561 8.3513
map() and itemgetter() (just for kicks): 9.1651
Unpacking is slightly faster for a tuple of a single item. This happens more often than you might thing; consider, for example, `struct.unpack(">H")`, which returns a tuple. Thus, use `val, = struct.unpack(">H")` in these situations instead of `val = struct.unpack(">H")[0]`. That said, use with care, since tuple unpacking is also slightly more unreadable than indexing, and so it does not seem that tuple unpacking causes a bottleneck for our software... yet. As the tuple grows, however, indexing is always faster. Also, as one might have suspected, `itemgetter` works more slowly than a list comprehension.
PyPy 1.6.0 (with GCC 4.0.1; Python 2.7.2)
Indexing vs. unpacking a 1-tuple: 0.2268 0.2279
Indexing vs. unpacking a 2-tuple: 0.2301 0.2302
Indexing vs. unpacking a 3-tuple: 0.2335 0.2320
Indexing vs. unpacking a 4-tuple: 0.2332 0.2344
Indexing vs. unpacking a list of 2-tuples: 1.2610 1.2698
map() and itemgetter() (just for kicks): 5.4586
There is no clear difference in pypy; both the indexing and unpacking operations seem to vary constantly. (I tested informally using a 250 item tuple. My test with 1000 slowed down unpacking considerably, but I suspect the bottleneck was with the source code parser, not the operation itself.) It is clear that map and itemgetter are significantly slower for pypy, however.
Jython 2.5.2
Indexing vs. unpacking a 1-tuple: 0.6510 1.1520
Indexing vs. unpacking a 2-tuple: 0.9610 0.7800
Indexing vs. unpacking a 3-tuple: 0.8930 0.8330
Indexing vs. unpacking a 4-tuple: 1.0250 0.8070
Indexing vs. unpacking a list of 2-tuples: 36.4800 40.4600
map() and itemgetter() (just for kicks): 11.0170
The Jython results varied from run to run, but it looks like unpacking was almost always faster. It also looks like Jython does not handle list comprehensions very well. Now you know.
Powers of Two
from timeit import Timer
# Use 62 to prevent slowdown from long ints
t1 = Timer("for i in xrange(62): 1 << i")
t2 = Timer("for i in xrange(62): 2 ** i")
times = 1000000
print "Bit-shifting vs. Exponentation:\t%.4f\t%.4f" % (t1.timeit(number=times), t2.timeit(number=times))
MacPython 2.7.2
Bit-shifting vs. Exponentation: 3.8654 8.3995
Bit-shifting wins by a longshot.
PyPy 1.6.0 (with GCC 4.0.1; Python 2.7.2)
Bit-shifting vs. Exponentation: 0.2184 2.0279
Again, bit-shifting wins by a longshot.
Jython 2.5.2
Bit-shifting vs. Exponentation: 2.6870 17.0960
Don't use Jython.