# 1691: Optimization

 Optimization Title text: Premature optimization is the root of all evil, so to start this project I'd better come up with a system that can determine whether a possible optimization is premature or not.

## Explanation

In computing, program optimization is the practice of making a computer program work as quickly as possible, typically by designing it to perform the fewest calculations. "Premature optimization" is the practice of trying to optimize parts of a program before such optimization has been shown to be needed. Optimization can prove to have been a waste of time if parts of the program are later changed or discarded, or if the optimized code is only a small part of the workload. Making a routine 10 times faster doesn't help much if that routine is only consuming 1% of the running time to begin with and it may result in more complicated and buggier code.

This comic is a flowchart making fun of the difference between prematurely optimizing and doing things right in the first place: it tells you that if you are using it to decide whether you are optimizing prematurely, then you're optimizing prematurely. The humorous conclusion is that if there is any doubt whether an optimization is premature, then it is premature!

Another layer of humor is provided by the minimalism and directness of the flowchart, which suggests that it has itself been (prematurely?) optimized.

The title text's root of all evil refers to Donald Knuth's paper "Structured Programming with Goto statements" (1974)[1] in which he wrote:

"There is no doubt that the grail of efficiency leads to abuse. 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%."

The title text takes the joke a step further by proposing optimizing a brand new project by introducing a procedure to determine whether a possible optimization is premature - which is obviously a premature optimization. It pokes fun at time-wasting behavior by obsessively perfectionist coders who develop tools to analyze aspects of their software, such as performance. In some fields, such as compilers or database design, such tools can be useful and productive (the 3% mentioned by Knuth?), but the usage suggested here is more appropriately covered by instinct, common sense, and observation of the behavior of the completed program.

The title text may also be poking fun at the comic, since the comic itself may be the "system" used to determine premature optimization.

Flowcharts are often used in xkcd including the (mostly) non-farcical 1688: Map Age Guide one week prior to this comic. Inefficiency (another xkcd theme) was featured in the comic prior to this one.

## Transcript

[A flow chart is shown with three boxes connected with two arrows. The first box is rectangular:]
Are you prematurely optimizing or just taking time to do things right?
[From the first box there is a short arrow straight down to a diamond shaped box:]
Are you consulting a flowchart to answer this question?
[A labeled arrow continues down.]
Yes
[The arrow connects to the final rectangular box.]
You are prematurely optimizing

# Discussion

141.101.98.47 08:33, 8 June 2016 (UTC) Yay! First time starting a page's explanation! (Actually second time, but first time I didn't save it in time.) Also, first comment!

Please don't start that again... 162.158.2.138 09:40, 8 June 2016 (UTC)

The flow chart has no branches. It has been optimized, by pruning branches which cannot apply. Are you consulting a flow chart cannot be answered no while consulting the flow chart, so the entire branch structure resulting from a no answer has been eliminated. However, there are many other ways in which premature optimization can take place, and there are some optimizations which are not premature, so this is a robust and fruit laden branch. Since it would be handy to keep that branch in mind, its removal is clearly premature. Therefore, this flowchart has been prematurely optimized.173.245.56.69 11:02, 8 June 2016 (UTC)

I guess that as soon as you are spending time on a flow chart on this question you are not using your time to do things right...--Kynde (talk) 11:11, 8 June 2016 (UTC)
I agree: It's not "if there is any doubt": It's specifically the flowchart. If you are consulting flowchart, you are either the kind of person who does everything methodically and waste gigantic amount of time by it, especially if trying to optimize, or you lack the experience and common sense needed to distinguish when the optimization is premature, and statistically are more likely to optimize incorrect part of code. But note the that most people, when citing the quote, forgot the "Yet we should not pass up our opportunities in that critical 3%." - and result is editor which have noticeable lag on computer which is capable of running 3D FPS game in 120fps. Worse: some decisions, while related to speed of program and therefore optimization, MUST be done early in planing - for example, what data structures will be used. If you start programming with linear list, it may be impossible to switch to B-tree later ; on the other hand, programming B-tree and then finding out the average length of list is 5 is typical premature optimization ; Therefore, you should either use existing library, which will be quick AND quickly written, or spend some time on writing abstract enough interface, so you don't waste too much time on the B-tree but will have option to put it there later without major refactoring. -- Hkmaly (talk) 16:25, 20 June 2016 (UTC)

Is this also an implicit reference to https://xkcd.com/1205/ (Is It Worth the Time)?Dani (talk) 11:44, 8 June 2016 (UTC)

Sigh... One of most misused quotes of all time. The original meaning of "premature optimization" was referring to fine-grained adjustments to assembly that made it much harder to read but a tad faster to run. It's not a justification for choosing a terribly inefficient approach, especially one that will be hard to replace later on. 162.158.91.50 14:11, 5 October 2021 (UTC)