3 ms·

I'm irked by the frequent use of "premature optimization is the root of all evil" without actually comprehending what Donald Knuth meant to say: "We should forg

by hliyan 9y ago

I'm irked by the frequent use of "premature optimization is the root of all evil" without actually comprehending what Donald Knuth meant to say: "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%". This quote is from an era where hardware resources were at such a premium that developers obsessed excessively over the performance impact of every line of code.

joshuata 9y ago
Also, you have to design for performance. There are plenty of ways to architect code that lock you out from future optimizations. I agree that small optimizations such as different referencing techniques should be measured, but you should be able try both out, and "premature optimization is evil" often keeps you from optimizing ever.
guscost 9y ago
The way I've used (and would recommend using) this idea is to spend some time deciding whether any big optimization is premature before implementing. By definition, premature optimizations cause more problems than they're worth, but appropriate optimizations pay dividends. You're absolutely right that the 97% number comes from a different time, but the central phrase is approximately as true as it ever was. The trick is that it can be really hard to determine whether a given optimization is premature. Like "one of the hardest things a working programmer will ever attempt" hard. One more thing: We optimize for factors other than CPU time, and all of the above still applies.
marcosdumay 9y ago
I do agree overall, but this fits the premature optimization case very well. Inlining/declaring functions is a micro-optimization that has no impact on the overall architecture, can be done/undone later without any problems, is a great target for optimizing in another level (interpreter, compactor, web-server), and will certainly not lead to any non-linear gain or loss. That quote was warning exactly about this kind of optimization, and it's foolish to trade anything (development time, maintainability, whatever) for that optimization without a business case and measurements.
c2h5oh 9y ago
I see this quote used way too often as an excuse for shitty, under-performing code. No, don't go down a micro-optimization rabbit hole when making the first rough prototype. Yes, do stop to think for 10 seconds to think how much use this code path will get and if there is a better way of doing it that will require similar amount of work to complete.

by hliyan 9y ago

joshuata 9y ago

Also, you have to design for performance. There are plenty of ways to architect code that lock you out from future optimizations. I agree that small optimizations such as different referencing techniques should be measured, but you should be able try both out, and "premature optimization is evil" often keeps you from optimizing ever.

guscost 9y ago

The way I've used (and would recommend using) this idea is to spend some time deciding whether any big optimization is premature before implementing. By definition, premature optimizations cause more problems than they're worth, but appropriate optimizations pay dividends. You're absolutely right that the 97% number comes from a different time, but the central phrase is approximately as true as it ever was. The trick is that it can be really hard to determine whether a given optimization is premature. Like "one of the hardest things a working programmer will ever attempt" hard. One more thing: We optimize for factors other than CPU time, and all of the above still applies.

marcosdumay 9y ago

I do agree overall, but this fits the premature optimization case very well. Inlining/declaring functions is a micro-optimization that has no impact on the overall architecture, can be done/undone later without any problems, is a great target for optimizing in another level (interpreter, compactor, web-server), and will certainly not lead to any non-linear gain or loss. That quote was warning exactly about this kind of optimization, and it's foolish to trade anything (development time, maintainability, whatever) for that optimization without a business case and measurements.

c2h5oh 9y ago

I see this quote used way too often as an excuse for shitty, under-performing code. No, don't go down a micro-optimization rabbit hole when making the first rough prototype. Yes, do stop to think for 10 seconds to think how much use this code path will get and if there is a better way of doing it that will require similar amount of work to complete.