"I approve too! But… Sometimes it just has to be fast, and sometimes that means the performance has to be designed in. Nelson agrees and has smart things to say on the subject."
- so... you're saying premature optimization isn't the root of all evil. Maybe it's time to retire this tired 'conventional wisdom'
Funny you mention it. I have a bit of a habit now of reminding people what the remainder of Knuth’s quote actually was.
“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 irony of walking away with the impression that Knuth was saying to not do optimization is that his point was the exact opposite of that, he was emphasizing the word premature, and then saying we absolutely should optimize, after profiling.
This all agrees completely with the article’s takeaways: build it right first, then measure, and then optimize the stuff that you can see is the slowest.
Anyone optimizing via microbenchmarks or wall time exclusively isn’t going to see this.
>> 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.
The only optimization type I understand that with is very isolated but convoluted fixes that buy performance at the cost of readability/etc. Intelligent architecture that is fast, so long as it is does not completely obfuscate the intent of the code, is not premature.
Identifying loops or recursion with many iterations (high N) with a high Big O order may also be avoided during the design stage, of you KNOW the N and O-order at design time. (And don't worry about the O-order for low N problems, that is premature optimization most of the time.).
On the other hand, tweaking every single statement or test in ways that save 1-2 cycles is rarely worth it. Often you end up with obfuscated code that may even make it harder for the compiler to optimize for. This is the 97% of the code where premature optimization makes things harder.
Some programmers may turn this on its head. They don't understand the implications of the design choices, but try to make up for that by employing all sorts of tricks (that may or may not provide some small benefit) in the main body of the code.
Even if we parse his "But..." as saying, "there exists some premature optimization which is not the root of an evil" (ignoring probably valid quibbles about whether the optimizations he's talking about truly are premature), this doesn't contradict the original statement.
In fact, "the root of all evil" seems to be an expression which invites us to commit the fallacy of denying the antecedent -- if premature optimization, then evil, in this case -- because it is almost always used to indicate that the first thing is bad.
I was going to "tongue-in-cheek overthinking" but I think it didn't really come through.