Keyvan Nayyeri

Stack Exchange websites and programming forums are a great way to share information specifically about techniques of programming, but as any other phenomena in our world, there is a downside to them when they’re misused. The fact that the questions on these sites are answered mostly by ordinary programmers makes them a bad resource for discovering and learning about concepts and principles (while they work great for techniques and practices). Many of these programmers leave their incorrect understandings of concepts and try to use irrelevant evidence to support their claims. One of these supporting evidence is quotes from famous computer scientists, something that usually works in a wrong way than a right one!

Background

One of the common quotes that is often misused by programmers as an excuse for being sloppy about their code performance is a famous one by Donald Knuth where he uses the term premature optimization.

Premature optimization is the root of all evil.

And no wonder if many programmers quote this short sentence out of a longer one (which is still incorrect as they don’t read the whole thing in the context of the original paper), and apply their own understanding of the raw English meaning of the word premature in there.

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

After writing my post on the performance penalties of DateTime.Now, I had to address this situation with one of these programmers who had the impression that he’s referring to Bible by quoting that short sentence from Stack Overflow, and I also saw the same thing happening on a recent blog post by Scott Hanselman where he used LINQ deferred execution for correcting a code!

It’s so sad to see this happening on the programmers community that is supposed to be open and look for the truth. Such a misleading hint for programmers will have one simple impact on the software being built: some programmers will not build higher quality software! It’s our responsibility as humans to talk about something when we have a minimum knowledge in it. Performance evaluation is a science with certain techniques defined but some people try to get over that by some tricks to prove that an optimization doesn’t work! It’s also the nature of programming and software development to mandate the programmer to be very open-minded and avoid biased views. If somebody has said something somewhere, it’s not a rule, and specifically in computers world, it has a good chance to be wrong.

Luckily, there have been some attempts by other programmers and computer scientists to address this problem, and the latest one was by Reed Copsey, Jr. who wrote a good blog post on it. Even on Programmers Exchange, Scott Dorman has a good response to one of these questions that is worth reading and sharing.

Having this background, I thought that it’s time for me to write my own post and describe several points related to optimization and premature optimization to clarify them because optimization is all I’m doing here at academia and it has taken most of my time in the past two years. I just hope that those programmers out there who tend to copy/paste some quotes on Stack Exchange websites, copy/paste these writings along with them, so the audience can decide what is right and what is wrong!

The Original Paper

I can bet that almost all people who use the term premature optimization in their literature are those who never read the original paper where the above sentence is written in even though that paper has a simple text which is easy to follow for all programmers! Knuth wrote a paper in 1974 to talk about structured programming with go to statements that obviously had a totally different focus and its primary intentions are useless in today’s computing because we don’t use GO TO statements in typical programming anymore!

As a part of the manual optimizations that he describes in that paper, he notes that programmers shouldn’t spend their time optimizing a code that is not obvious to be a bottleneck which can take their focus of the design of the program, and he refers to such a case as premature optimization. As I’ll write later, here he’s talking about a particular type of optimization (design-time optimization) and not all of the optimization levels. Besides, he’s clear that it’s a premature optimization if it affects the design of the program significantly which doesn’t apply to many cases where this term is misused by programmers to be sloppy. If you read the paper, you’ll be surprised what types of techniques are introduced in there to make a structured program and optimize its code. It covers techniques that are no longer used by programmers as they’re either removed from programming paradigms, or are hidden in the compilers.

So the first step is to read that paper, the whole thing, before quoting something out of that, and do not forget that the paper is written in 1974 and has a very clear goal regarding GO TO statements.

What is Optimization?

Unfortunately, most (not all) programmers don’t know a scientific definition for optimization, as they don’t know anything about something very related called performance evaluation! Most programmers believe that optimization is the task of modifying the source code of a program to just run faster which is only a part of the broader definition of optimization. Likewise, performance evaluation is nothing but calculating the execution time of a piece of code for them!

Optimization comes in different levels and forms to improve the efficiency of software and that efficiency should be defined. In a common sense efficiency consists of saving resources including time, CPU, memory, and disk, but it’s usually hard to achieve them altogether, and that’s why efficiency is defined on a per-case basis.

Levels of Optimization

One of the main points missing by programmers is that optimization comes at different levels and in different forms like low-level assembly code, compile-time, or runtime optimizations or higher-level optimizations like those applied to programming codes directly by programmers or even optimizations in design. This last level of optimization is the main one that Knuth is pointing to in his paper as he tries to emphasize that at the design time, we shouldn’t spend too much time and efforts or deviate from the main goal only in order to optimize something.

On the other hand, low-level optimizations like assembly code, compile-time, or runtime optimizations are vital to the execution of a program. In fact, without such optimizations, a reasonable number of the heavy programs written in today’s software world couldn’t run on the current hardware! In such cases, optimization is a need!

It may be interesting to know that in the current research world in compilers a very tiny optimization on a single architecture is the outcome of a research project for months and makes a good publication! We’re at a point where many of these low-level optimizations are the ultimate goal of the researchers.

Premature Optimization

But what is premature optimization really? Premature optimization has come from that paper by Knuth and is defined in those terms. What he really means by premature optimization is a type of optimization that is done at design time (or during the original coding process) that forces the programmer to take his focus off the design and add an extra complexity to the design that doesn’t add much to the performance. This is very clear from the text of the paper or even from the longer version of the quote that I’ve mentioned above.

However, there are many developers who interpret premature optimization as any optimization applied during the coding process that doesn’t have a big impact. Not only this is a wrong interpretation, but also it allows us to ask some simple questions that can’t be answered clearly by such programmers. One of them is a method to distinguish between a big optimization and a small one because there doesn’t exist a threshold for that.

Optimization or Recommended Practice?

The term premature optimization is used to kill many good authors by programmers when there isn’t an optimization going on! In fact, what is described to avoid a bad practice is considered an optimization which is totally wrong. Many times, we’re referring to a good or recommended practice that is forgotten and disregarded by programmers, and this is not an optimization.

A good example is my post on DateTime.Now’s performance penalties. This situation is a recommended practice that should be followed and there is nothing about optimizing your code. If you’re using DateTime.Now rather than DateTime.UtcNow in places where it’s not supposed to be used, then you’re doing something wrong, and it’s not an optimization to use DateTime.UtcNow. In these cases, you’re not optimizing anything. What you’re doing is correcting a mistake!

With the rise of virtual machine hybrid compilers like .NET and Java, and the complex transformations that they apply to the original code before running it on the hardware, it’s very important to follow some recommended practices by the builders of the compilers because these practices and recommendations are those that have a close relationship with the internal working of the compiler. These points have nothing to do with optimization. They’re the way things should be used, and they’re like the manual for this system.

Furthermore, even if we consider these circumstances as optimization, we should note that all these examples are not affecting our design. These are very minor changes to code that just make it work the way it’s supposed to work in the first place! These are the type of practices that should be followed at the coding time.

Excuse for Sloppiness

To rant a little bit about some programmers who really hurt the software community by the use of this premature optimization term, let me say that this, along with many other things that we hear from some (but not all) programmers, is just an excuse for sloppiness. Just like the people of the society, there are some professionals who care about many things and live open-minded and try to at least listen to others’ opinions, and there are also some close-minded people who want to stick to their beliefs and not care about what’s going on. You see that on the .NET community, too, where there are some people following ALT.NET to try the best practices, and there are also some people who hardly care about many of the new technologies introduced by Microsoft.

Throwing something like a quote on a valid statement is easy to fool yourself to not correct your mistakes, and there is nothing more than that. Let’s be real and respect other people’s expertise. When somebody with a long history of expertise and knowledge in the field is bothering himself/herself to publish something, there is enough thought behind that for us to at least spend some time thinking about his points.

Summary

The term premature optimization is mistakenly interpreted by some programmers and spread on programming forums to be used against many great writings on optimizations and best practices. The term premature optimization, introduced by Donald Knuth in an old paper doesn’t imply anything about not optimizing a code if it’s small. There is no smallness defined in performance evaluation to prevent optimization.

What premature optimization means is an optimization that has a little impact but keeps the programmer or designer busy during the design phase to change the design significantly. This, of course, is very different from many of the circumstances where a recommended practice is not followed or a small change without affecting the design can give us better results.