5 ms·

Slightly tangential, but I think "Premature optimization is the root of all evil." is the most misquoted statement in the history of computer science. Most imp

Slightly tangential, but I think "Premature optimization is the root of all evil." is the most misquoted statement in the history of computer science. Most importantly, people tend to misinterpret "premature" to mean "any time before the software is done" or similar. I can't even count the number of times where I've worked on or watched a project where performance is important and the following series of events occurs: 1. Module is designed with that quote in mind: it must be simple to implement and performance is unimportant. Note that this isn't a prototype: this is a plan for the actual final product. 2. Module is built and finished, then submitted for a review. The reviewers, knowing the importance of performance for this module, point out a number of ways that the module is extremely suboptimal. 3. Because of the assumptions so heavily ingrained into the module, implementing these performance improvements--which could have been foreseen as necessary far earlier--requires a near-complete rewrite of a large part of the module. It's exactly as if we finished our software and our customer decided that his requirements were actually totally different--except in this situation, it's entirely our fault, because performance was a requirement and we ignored it because we didn't want to optimize "prematurely". If you want performance, you have to design with performance in mind; if you don't, and then decide later you want performance, the cost of your earlier decision is magnified a hundredfold. I have almost never seen that quote used correctly.

barrkel 17y ago
Well, the fact that it says that something "premature" is causing a problem seems to me to mean that it's actually a tautology. It's like saying kids are immature; but of course, what is more of the nature of an immature person than a child? So yes, optimizations that are made before they should have been made, should not be made. It tells us little about optimizations other than that there is a time for which they are premature, and doing them at that time is premature.
- philh 17y ago
  I think the important bit is "the root of all evil": it also tells us that doing optimisations prematurely has the potential to destroy your project. Compare with something like, "premature optimisation will take a little longer to perform, and perhaps be not quite as optimal, but isn't that big a deal in the long run, really."
JulianMorrison 17y ago
I always though that what that one quote meant was: measure, then optimize. It's no use tuning the hell out of a function that hardly features in your profiler results.
- silentbicycle 17y ago
  Agreed, though it would be clearer if the quote went, "Uninformed optimization..." or "Doing optimization without measuring first...".
- xsmasher 17y ago
  That, and also optimizing code that later gets thrown out entirely because requirements or other factors change. There's no benefit to optimizing code that goes in the bit bucket.
- cschep 17y ago
  Yes, or even just figure out HOW (you're going) to measure it.
billswift 17y ago
Maybe someone should come up with a clearer statement, "Don't optimize beyond need", for example. At least it's suggesting that there can be a need for optimization, and that too much optimization can be a problem.
wglb 17y ago
That is why the rewording I use is "First make it right, then make it fast". If you make it fast first, then that is premature optomization.
- ajross 17y ago
  But that's just saying the same thing. The point being made above is that working "correctly" simply isn't enough if performance is a design goal too (or rather, correct operation requires that the software meet the performance goals at design time). So if you start out working on only half the problem, you'll still fail.
  - wglb 17y ago
    My experience has shown me that it is very difficult to know where the performance bottlenecks are without measurement. You can't measure it if you haven't built it, and if it is not correct, why bother? I have always taken this to mean what the original "premature optimization" quote is all about. I felt that making the statement a little simpler helps my focus.
Locke1689 17y ago
You have a good point, but I don't think I asserted that any of those points are correct. I mostly agree with JulianMorrison on this one, although I think sometimes you can see performance bottlenecks coming. If you know an inner loop needs to be faster than your interpreted language can normally do, you might as well write that segment in C or ASM from the beginning. Mercurial still seems to me like a good example of optimization done correctly.
SapphireSun 17y ago
There is an intermediate state where you make it "just work" but design it so that it's easy to speed up the algorithms later. Premature optimization makes you waste time on dumb stuff, but leaving yourself a way out is a lot less costly than optimizing everything and lets you avoid the problem you mentioned.
gruseom 17y ago
Wow, did you ever hit the nail on the head. I've been saying this for a long time (edit: e.g. http://news.ycombinator.com/item?id=96186 http://news.ycombinator.com/item?id=96186, http://news.ycombinator.com/item?id=173949 http://news.ycombinator.com/item?id=173949), wondering why I'd never run across anybody making what seems an obvious point. At last I have! The important decisions around performance have to do with design, not optimization. Knuth's original principle was quite explicit: forget about most small efficiencies. But people commonly use it to justify not thinking about large ones. "Don't micro-optimize prematurely" somehow got changed into "don't think about performance until the end of the project".

barrkel 17y ago

Well, the fact that it says that something "premature" is causing a problem seems to me to mean that it's actually a tautology. It's like saying kids are immature; but of course, what is more of the nature of an immature person than a child? So yes, optimizations that are made before they should have been made, should not be made. It tells us little about optimizations other than that there is a time for which they are premature, and doing them at that time is premature.

philh 17y ago
I think the important bit is "the root of all evil": it also tells us that doing optimisations prematurely has the potential to destroy your project. Compare with something like, "premature optimisation will take a little longer to perform, and perhaps be not quite as optimal, but isn't that big a deal in the long run, really."

JulianMorrison 17y ago

I always though that what that one quote meant was: measure, then optimize. It's no use tuning the hell out of a function that hardly features in your profiler results.

silentbicycle 17y ago
Agreed, though it would be clearer if the quote went, "Uninformed optimization..." or "Doing optimization without measuring first...".
xsmasher 17y ago
That, and also optimizing code that later gets thrown out entirely because requirements or other factors change. There's no benefit to optimizing code that goes in the bit bucket.
cschep 17y ago
Yes, or even just figure out HOW (you're going) to measure it.

billswift 17y ago

Maybe someone should come up with a clearer statement, "Don't optimize beyond need", for example. At least it's suggesting that there can be a need for optimization, and that too much optimization can be a problem.

wglb 17y ago

That is why the rewording I use is "First make it right, then make it fast". If you make it fast first, then that is premature optomization.

ajross 17y ago
But that's just saying the same thing. The point being made above is that working "correctly" simply isn't enough if performance is a design goal too (or rather, correct operation requires that the software meet the performance goals at design time). So if you start out working on only half the problem, you'll still fail.
- wglb 17y ago
  My experience has shown me that it is very difficult to know where the performance bottlenecks are without measurement. You can't measure it if you haven't built it, and if it is not correct, why bother? I have always taken this to mean what the original "premature optimization" quote is all about. I felt that making the statement a little simpler helps my focus.

Locke1689 17y ago

You have a good point, but I don't think I asserted that any of those points are correct. I mostly agree with JulianMorrison on this one, although I think sometimes you can see performance bottlenecks coming. If you know an inner loop needs to be faster than your interpreted language can normally do, you might as well write that segment in C or ASM from the beginning. Mercurial still seems to me like a good example of optimization done correctly.

SapphireSun 17y ago

There is an intermediate state where you make it "just work" but design it so that it's easy to speed up the algorithms later. Premature optimization makes you waste time on dumb stuff, but leaving yourself a way out is a lot less costly than optimizing everything and lets you avoid the problem you mentioned.

gruseom 17y ago

Wow, did you ever hit the nail on the head. I've been saying this for a long time (edit: e.g. http://news.ycombinator.com/item?id=96186 http://news.ycombinator.com/item?id=96186, http://news.ycombinator.com/item?id=173949 http://news.ycombinator.com/item?id=173949), wondering why I'd never run across anybody making what seems an obvious point. At last I have! The important decisions around performance have to do with design, not optimization. Knuth's original principle was quite explicit: forget about most small efficiencies. But people commonly use it to justify not thinking about large ones. "Don't micro-optimize prematurely" somehow got changed into "don't think about performance until the end of the project".