Thou shalt not optimize

It’s the kind of commandment that would actually impress me if it were in the Bible, something obviously outside the knowledge of a primitive people living in the Middle East millennia ago. It’s quite lame to have a book that was supposedly dictated by God, but only contains stuff that they could come up with it themselves. God could just dictate the first 100 digits of $\pi$ to demonstrate that people were not just making shit up. There’s a novel by Iain Banks, The Hydrogen Sonata, that has this as key plot point: as a prank, an advanced civilization gives a “holy book” to a primitive society from another planet containing all sorts of references to advanced science that the latter hadn’t developed yet. The result is that when the primitives eventually develop interstellar travel, they become the only starfaring civilization in the galaxy that still believes in God.1

Why not optimize, though? The main reason is that I have carefully optimized some code that I was developing, only to realize that it was entirely the wrong approach and deleted the whole thing. It wasn’t the first time this happened. Nor the second. Nor the third. But somehow I never learn. I think optimization is addictive: you have a small puzzle that is interesting to solve and gives you immediate positive feedback: yay, your code runs twice as fast! It feels good, it feels like progress. But in reality you’re just procrastinating.

Instead of spending one hour optimizing your code, just let the slow code run during this hour. You can then take a walk, relax, get a coffee, or even think about the real problem, trying to decide whether your approach makes sense after all. You might even consider doing the unthinkable: checking the literature to see if somebody solved a similar approach already and their techniques can be useful for you.

Another reason not to optimize is that most code I write is never going to be reused, I’m just running it a couple of times myself to get a feeling about the problem. It then really doesn’t matter if it takes ten hours to run, but you could optimize it to run in ten minutes instead. Just let it run overnight.

Yet another reason not to optimize is that this really clever technique for saving a bit of memory will make your code harder to understand, and possibly introduce a bug.2 What you should care about is having a code that is correct, not fast.

On the flipside, there are optimizations that do make your code easier to understand. I saw a code written by somebody else that was doing matrix multiplication by computing each matrix element as $c_{i,j} = \sum_k a_{i,k}b_{k,j}$. That’s slow, hard to read, and gives plenty of opportunity for bugs to appear. You should then use the built-in matrix multiplication instead, but the optimization is incidental, the real point is to avoid bugs.

There are two exceptions to the “thou shalt not optimize” commandment that I can think of: the first is if your code doesn’t run at all. Sometimes this indicates that you’re doing it wrong, but if you really can’t think of something better, yeah, optimizing it is the only way to get an answer. The second is if your paper is already written, the theorems are already proven, you’re certain your approach is the correct one, and you’re about to publish the code together with your paper. Then if you optimize it you are a great person and I’ll love you forever. Just remember to use a profiler.

This entry was posted in Uncategorised. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *