# 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", "tpl = (5,)")
unpack1 = Timer("x, = tpl", "tpl = (5,)")
index2 = Timer("x = tpl", "tpl = (5, 6)")
unpack2 = Timer("y, x = tpl", "tpl = (5, 6)")
index3 = Timer("x = tpl", "tpl = (5, 6, 7)")
unpack3 = Timer("y, y, x = tpl", "tpl = (5, 6, 7)")
index4 = Timer("x = tpl", "tpl = (5, 6, 7, 8)")
unpack4 = Timer("y, y, y, x = tpl", "tpl = (5, 6, 7, 8)")

list_index2 = Timer("[tpl 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")`. 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.