Premature optimization isn't the root of all evil

  Thursday, April 7, 2016 » programming

Ask a question regarding the performance characteristic of some piece of code on the Internet and you’ll end up reading an answer along the lines of “premature optimization is the root of all evil”.

I’m starting to get sick of reading those answers. Optimizations aren’t evil.

What is wrong with optimizations?

I think there are different reasons why people advice against doing performance optimizations.

1) They don’t believe that (micro-)optimizations make much of a difference.

They’re wrong. Just read this entry out of the SQLite change-log:

Miscellaneous micro-optimizations result in 22.3% more work for the same
number of CPU cycles relative to the previous release. SQLite now runs
twice as fast as version 3.8.0 and three times as fast as version 3.3.9.

Once you start looking, you start reading a lot of similar stories.

Because of the same reason people often advice to not worry about performance until profiling has revealed that a piece of code is a bottle neck.

This sounds reasonable. Profiling is great to identify hot spots. But what do you do once the hot spots are eliminated and you still haven’t met the performance requirement?

Death by a thousand paper cuts.

2) The time spent on the optimization is a waste because the application doesn’t have that kind of performance requirement.

To some degree this is a legit reason. Performance is a feature that (might) come at a price. Sometimes it is not worth paying that price. If I toy around with my home-automation solution I don’t care about performance. When I’m writing a database I certainly do.

But it is still a lousy reason to answer a question with “premature optimization is the root of all evil” because of three assumptions:

  1. The assumption that the application isn’t performance critical.
  2. The assumption that it is more effort to implement a better performing solution.
  3. The assumption that better performing code is more difficult to read.

The second and third assumptions aren’t always true. Often it is just about not using the wrong abstractions. It can take an initial learning effort, once learned using the superior variant becomes free.

Consider the following trivial example:

    String x = String.format("x:%s_foo", input);

    String x = "x:" + input + "_foo";

(This is Java code: The second variant is faster)

tl;dr

  • If you answer performance questions on Stackoverflow with “don’t worry about it”: Please stop. It doesn’t help the person who asked the question. If you insist, add it as disclaimer to an actual answer.

  • Writing efficient code doesn’t necessarily imply hard to read or high effort. It’s about learning what (unnecessary) work abstractions might do and then choosing the right ones.