I was having some trouble installing a network card on my home server. It wasn’t being autodetected. I’m weak on Linux hardware stuff, and networking in particular (since it’s always *just worked*), so this was starting from scratch. I had a few extra handicaps, in that I didn’t have the orginal box, and this card was one I’d bought months ago, physically installed, and forgetten to configure, so my bad! I didn’t even know the model number!
read on to see how I got it working
“Being this easy ain’t cheap.” “There’s no such thing as a free lunch.”
We’ve all heard these tropes before, right? Sometimes, without testing, it’s hard to see exactly how much that lunch costs. This week’s example: Python’s copy.deepcopy.
I tend to fancy myself as using a lot of functional programming techniques in my code, and as part of that, I try to avoid modifying data by side-effect. Deepcopy makes it easy to copy the original structure, modify the copy, and return it. After some profiling and timing work, I saw that, of all things, deepcopy was the bottleneck!
Sure, it’s bulletproof, battle-tested, and designed to do the Right Thing ™ in almost every case! But for simple data structures, it can be overkill, since it does so much accounting, reference tracking, and the like.
Most of the data I see in my day job has simple formats: mainly dictionaries of lists, sets, strings, tuples, and integers. — the basic python types we know and love, easily representable (in plain text, html, tables), and easy to munge / transmit (using JSON or the like). In short, they’re nice to work with, and transparent.
As it turns out, when we control the input data, we don’t need to worry as much about robustness. Sure the code below for “deepish_copy” doesn’t handle classes, and nested iterables, or generators, or even nesting to arbitrary depth. But, it runs fast, as the speed results below show.
import timeit from copy import deepcopy def deepish_copy(org): ''' much, much faster than deepcopy, for a dict of the simple python types. ''' out = dict().fromkeys(org) for k,v in org.iteritems(): try: out[k] = v.copy() # dicts, sets except AttributeError: try: out[k] = v[:] # lists, tuples, strings, unicode except TypeError: out[k] = v # ints return out def test_deepish_copy(): o1 = dict(name = u"blah", id=1, att0 = (1,2,3), att1 = range(10), att2 = set(range(10))) o2 = deepish_copy(o1) assert o2 == o1, "not equal, but should be" del o2['att1'][-1] assert o2 != o1, "are equal, shouldn't be" #prun for ii in xrange(1000): o2 = deepcopy(o1) #prun for ii in xrange(1000): o2 = dc2(o1) o1 = dict(name = u"blah", id=1, att0 = (1,2,3), att1 = range(10), att2 = set(range(10))) a = timeit.Timer("o2 = deepish_copy(o1)","from __main__ import deepish_copy,o1") b = timeit.Timer("o2 = deepcopy(o1)","from __main__ import deepcopy,o1") # 64-bit linux, 1 gHz chip, python 2.4.3 a.repeat(3,number=20000) # [0.45441699028015137, 0.41893100738525391, 0.46757102012634277] b.repeat(3,number=20000) # [2.5441901683807373, 2.5316669940948486, 2.4751369953155518]
Using the custom written code speeds things up quite a bit (5 fold!). For me, where this copying *was* the bottleneck, and I have to iterate over hundreds of thousands of these things, it made a noticible difference in total run time. Taking the 10 minutes it took to write this code was worth it. So was profiling (using ipython’s simple %prun macro).
As always, to end with another cliche: your mileage may vary… but if you’re not relying on the car manufacturers to degisn an engine for exactly your needs, you can probably improve it.