Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 61 down vote favorite
13

Often I hear the sentiment ...

"Why worry about performance, write slow code, get your product to market ... don't worry about performance. You can sort that out later"

The culmination of this sentiment is:

"... premature optimization is the root of all evil ... #winning"

I was wondering, does anybody have a good retort to this one liner. Ideally an equally strong one liner that encompasses the reverse of this sentiment?

share|improve this question
24  
Isn't the original: "the LOVE of money is the root of all evil?" – barrycarter May 28 '11 at 15:41
69  
The correct sentiment is not to "write slow code" but rather to write the simplest possible implementation that can be easily and quickly implemented (i.e. code which saves your psychological health and time), and to ignore performance constraint until you know that it matters. – Lie Ryan May 28 '11 at 16:22
13  
@barrycarter I believe the most scholarly translation is "The love of money is the root of all kinds of evil." – ErikE May 28 '11 at 18:06
10  
"Premature pessimization is the root of unuseable software" – quant_dev May 28 '11 at 20:54
9  
@Django: Because it's invariably used as a petulant excuse for criminally inefficient designs? – Aaronaught May 28 '11 at 22:20
show 24 more comments

closed as not constructive by gnat, Caleb, Jimmy Hoffa, Giorgio, GlenH7 Apr 17 at 17:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

37 Answers

1 2
up vote 35 down vote accepted

I find the best retorts to be:

  • "polly want a cracker?"
  • mindless mantras are anathema to productive thought
  • dogma smothers karma
share|improve this answer
8  
+1 for point two! – Max May 28 '11 at 15:08
8  
@Tchalvak: I think it means parrots just repeat what they've heard, and so do some programmers. – Mike Dunlavey May 28 '11 at 18:46
5  
How about "So's your face?" – glenviewjeff May 29 '11 at 3:09
30  
Kunth's quote is not "mindless mantra" it is taken out of context by people that don't understand its meaning, and make it mean whatever they want it to mean personally, much like any religious text that is mis-quoted and twisted around. The key word is PREMATURE which means, optimization before you actually KNOW what you need to be focusing on. – Jarrod Roberson May 29 '11 at 18:18
6  
@Jarrod: the question was a request for retorts. No one is questioning Knuth's wisdom. Calm down. Breathe. There. OK, now consider that for people who don't understand its meaning and who quote this out of context, it becomes a mindless mantra. Q.E.D. ;-) – Steven A. Lowe May 29 '11 at 18:35
show 10 more comments
up vote 172 down vote

The point of that statement is not to imply that you should write slow code or sloppy code just to get it done quickly, and someone who states it as you did "write slow code, get your product to market", is greatly misinterpreting it.

It's point is that you should not spend time micro-optimizing code that has not yet proven to be problematic.

The implication is that you aim to build a complete, well thought-out, and functioning application before squeezing out extra CPU cycles.

So I haven't answered your question. I offer no retort, other than to correct them about the purpose of avoiding premature micro-optimization.

Addendum As I was cooking breakfast, I thought of a better summation:

When developing new code, the time you might spend micro-optimizing every for-loop is much better spent thinking about higher-level organization and integration. That time spent on organization & integration at the earlier stages pays dividends when the time comes that you actually do need to optimize a component; a localized refactoring or optimization is likely then to require less rewriting and of surrounding code.

share|improve this answer
8  
This is a great answer, and it's so true. You can easily get caught up in micro problems simply because they're more in your face. It's harder to force yourself to look at the macro and make sure that the architecture is doing what it should be first. – Django Reinhardt May 28 '11 at 23:44
25  
Don't leave us hanging. What'd you cook for breakfast? – Jordan May 29 '11 at 2:21
1  
@Jordan Nothing special, just eggs on biscuits for my kids. Offers extra time to develop more sophisticated coding philosophies. – Michael May 29 '11 at 12:55
14  
@Michael: you could crack the eggs on top of the biscuit dough and put the whole thing in the microwave for 2 minutes, but that might be premature optimization – Steven A. Lowe May 29 '11 at 17:01
show 4 more comments
up vote 54 down vote

"don't worry about performance" and "premature optimization is the root of all evil" are not saying the same thing.

One is saying, don't worry about optimizing. The other is saying, don't worry about optimizing until you have the blunt of the application written and profiled, because what you think the critical 3% will be and what the critical 3% actually is are usually two different things.

Thus, you should optimize, just don't do it prematurely.

share|improve this answer
1  
I think 3% is way more than what really counts. Other than waiting on the disk my experience is that the vast majority of time is spent in a few places--loops with very high run counts, sometimes routines called from within such loops. I've never found this to be even 1% of the code. – Loren Pechtel May 29 '11 at 2:26
2  
s/usually/surprisingly often/ – Pete Hodgson Sep 26 '11 at 6:50
up vote 38 down vote

I can't believe nobody has suggested to complete the original quote. The full quote is

We should forget about small inefficiencies, say 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code, but only after that code has been identified.

Donald Knuth

Sure, Knuth said it, but he said it in a manner which specifically limits what he's talking about. Someone taking this out of context in order to make a point clearly doesn't understand the original point Knuth was making.

Therefore, my response would be to ask them to read the original text again, specifically the paragraph before and after the bit they are quoting.

share|improve this answer
2  
Another retort, which is from the same article appears just before the above quote: The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers, who can't debug or maintain their "optimized" program. – Allon Guralnek Nov 3 '11 at 18:54
up vote 28 down vote

Best retort is obviously "it shows up on the profiles I've done".

share|improve this answer
3  
If the optimisation was premature, this seems unlikely to be true. To show an improvement by profiling, you need to have measured the before and the after. If you measured first and had determined there was a real problem, the optimisation isn't premature. – Steve314 May 28 '11 at 19:28
2  
@Steve, Actually the optimization could still be premature, if you think about it. You could be sitting there trying to shave (measurable) seconds from an SQL Stored Proc that only gets called once a month. Those improvements would show up on profiles... just ones that aren't important to the project's success. – Django Reinhardt May 29 '11 at 0:06
2  
@Django - The point of measurement is to identify bottlenecks, not just to say "module x takes y microseconds to run with data z". Referencing profiles in a retort that show measured but irrelevant savings would be a risky bluff too - someone may ask to see those profiles, and easily see the flaw. – Steve314 May 29 '11 at 10:21
show 1 more comment
up vote 28 down vote

Premature shipping is the root of all failure.

(In other words, a minor nuisance in design/coding like poor performance quickly turns into full-blown production failure once it's shipped. So don't be stupid and don't write sloppy code.)

share|improve this answer
2  
What would you call never shipping, if not failure? Perfection, including the best possible performance, is an unachievable goal. – jmoreno May 28 '11 at 18:27
2  
@jmoreno: With the possible exception of Duke Nukem Forever, no software project "never ships" unless it's abandoned, which in the majority of cases is because the project has already failed for other reasons. Anyway, your question is entirely missing the point; you don't need to ship a perfect product, but you are responsible for shipping something that actually works, and in most cases "works" carries implications of acceptable performance levels. – Aaronaught May 28 '11 at 19:01
1  
@jmoreno: Think twice about being first to market. Familiar term, yes; infallible one, absolutely not. In fact, I'd wager that the majority of software products you use today were developed and shipped by companies that were not, in fact, first to market. Not to say that performance was the singular reason why me-too'ers pulled ahead, but shipping first isn't always a great reason to cut corners. – Aaronaught May 28 '11 at 22:16
show 3 more comments
up vote 23 down vote

It doesn't have an easy corollary, because it's true almost by definition.

It's not saying to write slow code, it's not saying optimization in general is bad. It's saying that optimization is not free, it comes at the cost of other (often more important) quality metrics, such as readability or flexibility, so you want to defer doing it until you know it's necessary.

pre·ma·ture
1. Happening or done too soon, especially before the natural or suitable time.
-- Cambridge Dictionary

This doesn't mean you should be completely unmindful of performance. It doesn't mean that if you know in advance a section of code is performance critical, that you shouldn't design it accordingly. But it does mean that if you're unrolling a loop in some routine that prompts for user input, you're probably doing it wrong.

share|improve this answer
2  
Too true... it seems everyone takes this as if the word premature was not in the sentence. Optimization, when it's needed and appropriate, is not premature, by very definition. – Software Monkey May 28 '11 at 23:07
2  
"....that you shouldn't design it accordingly." The distinction is between design for performance and code for performance. Quite different, and one gives much greater returns the other. Code for performance is rarely cost effective and usually premature. – mattnz May 30 '11 at 3:57
up vote 17 down vote

"yeah, but mature optimization is divine"

share|improve this answer
1  
Nice, that's what I was about to write... I think. It's hard to know now, since you already wrote it. +1 – Yar May 28 '11 at 15:09
2  
Isn't that just backing-up the same statement? Shouldn't it be, "Yeah, AND mature optimization is divine". – Django Reinhardt May 28 '11 at 23:43
up vote 15 down vote

I would ask them to explain the quote. And then help them understand it.

People repeat it as some mantra. It could have been written in Latin and Old Greek for all that matters, they would not think about it anyway.

Typically it gets started like this:

Alice: Is if (i == 0) faster than if (0 == i) ?

Bob: don't worry about this, as Knuth said "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. "

Alice (disappointed and subdued): Oh! Ah yeah I heard about this already. -- don't want to appear too dumb right ?

Later on:

Carol: I think we should review our algorithm here, O(N!) is pretty bad and won't allow us to scale at all.

Alice: It's okay, Knuth said it: "Premature Optimization is the root of all evil"! -- great sense of accomplishment

This quote is too widespread, I fear, and most of the times provided without any context. It's basically the equivalent to the unfamous RTFM. People get bashed on the head with this, and they don't want to appear dumb since they didn't know about this and everyone seems to, so they shut up and forget to ask why ??.

And then they reuse it themselves, propagating it, and not necessarily in appropriate situations because they have never been given the necessary information to judge whether or not it applied to a particular situation.

It's a vicious circle we are in, since when those cultists reuse it, they cannot provide the context at all, because they never knew it in the first place. But it comes from Knuth, the K in KMP!, the one behind Latex, the one behind "The Art of Computer Programming", so it cannot be wrong... right ?

share|improve this answer
6  
To be fair, give credit to Alice for at least asking a co-worker whether (i == 0) is faster than (0 == i), rather than posting a question on StackOverflow like most people do. – Carson63000 May 28 '11 at 23:09
1  
This is my exact reaction to the quote. Sure, let's see if we can stack up some O(N) operations and make our screen refreshes O(N^40). Then hand it off to someone else to fix, because it works with our test code (N<5). I have been on the "fix" end of that equation and it sucked. – Мסž May 29 '11 at 4:48
show 3 more comments
up vote 11 down vote

The best retort might be to memorize Knuth's entire bit about optimization and repeat it back to them. It's unlikely they'll ever say anything to you about optimization again! :)

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%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

Donald Knuth, 1974

share|improve this answer
up vote 9 down vote

Belated pessimization is the leaf of no good.

share|improve this answer
1  
+1 That's hilarious. And very nearly makes sense! – Rex Kerr May 28 '11 at 23:41
show 1 more comment
up vote 7 down vote

"This is not premature optimization; it is avoiding gratuitous pessimization." (Herb Sutter, Andrei Alexandrescu "C++ Coding Standards")

Certain efficient design patterns and coding idioms are just as easy to write as pessimized alternatives.

share|improve this answer
1  
make sure they are as easy to read too :) – Jaap May 29 '11 at 12:32
up vote 5 down vote

Test first!

When you write essential load tests, in most cases you can judge if an optimization is premature or not.

Mind your complexity!

When you currently have an algorithm that's n^4 and you know need answers for n=1000 in 1 minute, you can start with an optimization right away.

share|improve this answer
show 2 more comments
up vote 4 down vote

As Michael said in his post, the saying is not meant to imply that code should be written to be slow.

If you need a quote to counter those who misinterpret the quote to mean delivering sub-par software, then I like these:

  • Do it right the first time.
  • Why is it we never have time to release good software but we always have time for production support?
  • Penny-wise, pound-foolish.
  • Performance is important. We should not assume our application is the only one running on the user's computer.
share|improve this answer
show 1 more comment
up vote 4 down vote

It's something that some programmers tell other programmers to express disapproval of how they are working. (Not that I haven't.)

In real, big, software, you'd better give some thought to performance early on, especially in the overall architecture. I can give some juicy examples of where this wasn't done.

share|improve this answer
up vote 4 down vote

The best retort was by Charles Cook in his blog entry from 4 Jun 2002 on Premature Optimization. The important line he said was:

But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems.

This blog entry by Charles Cook was selected by Randall Hyde in his book: "Write Great Code" published 2004.

share|improve this answer
up vote 4 down vote

It might be more useful to ask a question instead, e.g. "why do you consider this optimization to be premature?" rather than getting into an exchange of quips.

share|improve this answer
up vote 2 down vote

It refers to the optimisations that are done in isolation, at a lower level with no regards to the overall picture. I suppose the slim chances that Knuth gives it to them are the places where someone did not care to do the optimisation after certain level down the hierarchy.

So a retort would be to go at least one level higher than who is telling you this, and, tell this same statement on their face. But I am not sure if it would be seen as a retort or a statement from someone who has gone through enough to come out a more mature person.

share|improve this answer
up vote 2 down vote

If by evil you mean wasted effort, isn't sloppy design even more evil?

share|improve this answer
show 1 more comment
up vote 2 down vote

"Caring about your craft is not evil."

"Getting something right the first time, saves time."

"I know I can make it better."

share|improve this answer
up vote 2 down vote

When your code is functional, then optimization is no longer premature.

Optimization is premature when you spend time on making your code fast but your code doesn't do anything. It doesn't matter how fast your code is if it's unfinished or not useful.

But once it is useful, it makes sense to look for measurable performance gains that will improve the user experience.

share|improve this answer
up vote 1 down vote

Starting with the least optimal algorithm is simply lazy, though; ideally, you pick a point in the middle.

share|improve this answer
up vote 1 down vote

How early is premature ? I mean, isn't it relative? Premature optimization for you might be a prototype under testing for me.

share|improve this answer
2  
"premature" basically should always be taken to mean 'before you've measured the existing performance and compared that to your requirements for performance'. The important thing here is that you also have to have some notion of what your expected/required performance is also. Most people who go about doing premature optimization don't. – whaley May 28 '11 at 13:26
1  
there's a long tradition in programming of micro-optimising because it's more fun that what you should be doing, or out of pride or worrying what people will think. The "worrying" can be valid, if the people are your customers and their thoughts are likely to be angry or frustrated - but they may be more angry about late delivery than slow performance. For pride, you probably can't afford for everything you make to be a work of art - and it's better, to a point, to take pride in readability and maintainability. – Steve314 May 28 '11 at 21:43
show 1 more comment
up vote 1 down vote

sure.. "a good design in the first place means you won't have to optimise later"

share|improve this answer
up vote 1 down vote

I would say: "premature software design and planning is more important than programming itself"

In short, you better start to think about what you are going to code rather than typing it without planning what it is going to do; you will make tremendous optimisation with a good design than optimization.

share|improve this answer
up vote 1 down vote

The correct "retort" in all cases, is to complete the quote completely and educate them what he intended.

We should forget about small inefficiencies, say 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code, but only after that code has been identified.

Donald Knuth
share|improve this answer
up vote 1 down vote

Premature optimization != early optimization.

I don't like how people try to use this quote as an excuse to not think about the problem at hand. Premature optimization means that it is occurring before the programmer knows that it actually makes a difference...this is sound advice. That doesn't mean that no optimization should occur before measuring; a good programmer can identify many performance bottlenecks without first measuring them (and profiling can help in less obvious situations).

share|improve this answer
2  
See Django Reinhardts longer quote of Knuts words: It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. It's more or less the opposite of what you say. – user unknown May 30 '11 at 2:27
show 4 more comments
up vote 1 down vote

I usually hand the person saying this my iPhone 3G, and ask them to bring up and use one of Apple's built-in apps (like mail or SMS) while I count the seconds out loud.

On a good day, my phone takes over twenty seconds to display text messages because some programmer at Apple was fond of repeating this cliche.

share|improve this answer
up vote 1 down vote

"Performance is a feature!" - Jeff Atwood, StackOverflow Podcast

This is the correct retort to: "Why worry about performance, write slow code, get your product to market ... don't worry about performance. You can sort that out later".

Premature optimisation is a very different thing.

share|improve this answer
up vote 0 down vote

Say the quote in its entirety. Remember, 3% of the time (at least according to Knuth), it is not the root of all evil.

share|improve this answer
2  
the problem, of course, is that very few people can identify what the 3% really is and end up wasting time on what they think the 3% is – whaley May 28 '11 at 13:20
4  
The full quote is, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." Emphasis mine. – greyfade May 28 '11 at 14:13
6  
@greyfade Nope. 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%. – alternative May 28 '11 at 15:19
3  
-1 (if I could) for misinterpreting the quote. He's not saying that 3% of the time we should prematurely optimize; he is saying 3% of the time we should worry about the small optimizations. Finding those 3% of cases can only be done once the entire application is written and profiled, at which point the optimization can hardly be considered "premature." – BlueRaja - Danny Pflughoeft May 28 '11 at 17:25
2  
@mathepic If you were to say the quote in its entirety, you'd see the Donald Knuth disagrees with you: It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. – BlueRaja - Danny Pflughoeft May 29 '11 at 23:24
show 6 more comments
1 2

Not the answer you're looking for? Browse other questions tagged or ask your own question.