It was only an example. Your commend ignores a programming fundamental: "premature optimization is the root of all evil". Clarity and simplicity for the programmer trump performance every time. Only in extreme cases, worry about it later, and don't use that as an excuse to break things for the rest of us.
When it's right to optimize: when (a) everything works, and (b) performance has become a meaningful cost, making it the most important issue to work on.
When it's right to care about simplicity and clarity: absolutely all the time.
> When it's right to optimize: when (a) everything works, and (b) performance has become a meaningful cost, making it the most important issue to work on.
Incorrect. There are things people do all the time with the understanding of mature optimization techniques. We know, for example, that certain algorithms perform better then a simple brute force technique, so we start there We might test various algorithms, too, before everything works. But we are testing.
Premature is not about time. It's about effectiveness. Sometimes you cannot gauge effectiveness until everything works, sure. But often times this is not the case.
I'm not denying there's better code and worse code in a performance-measurable sense that's written before 'optimization' goes on later in a project.
However, in the real world, we deal with problems. If you have a performance characteristic that's causing issues and you can reproduce it, then you have a problem and you can work on it. The inverse is also true.
Point of premature optimization quote: Most of the time more than a passing / higher-level-architectural thought about performance is not a good idea.
