4 ms·

Warnings against premature optimization suggest a two-pass strategy, where in the first pass you avoid trading increased performance for increased labor, and th

by adrusi 6y ago

Warnings against premature optimization suggest a two-pass strategy, where in the first pass you avoid trading increased performance for increased labor, and then in the second pass you do whatever is needed to make the performance good enough. The faster the underlying platform, the less work is required to get to "good enough" performance, so this strategy absolutely leads to software not getting faster as hardware gets faster, and the only way for an end-user to get their software to run fast is to have faster hardware than is typical for the target market for that software. I don't think it's much of a stretch to call a development paradigm that causes software to never get faster even as hardware improves "writing slow programs on purpose."

erik_seaberg 6y ago
Part of the reason for writing the slow version is that you need to profile it to find out where the problems actually are, because intuition is not a very good guide. Some of the worst bottlenecks seem tiny but happen so frequently they add up, while a lot of things that sounded slow don’t actually matter.
- carlmr 6y ago
  That's also the thing with premature. I would agree with you that premature is before you know what's slow. But if you have a CI Profiling run showing a few hotspots it's not premature anymore. Still people quote this adage. Further there are things you should know are usually performance issues, that I would expect you to avoid entirely, except with good reason. Using O(N²) or worse algorithms on big collections when there are much faster alternatives in the standard library of your language for example. I don't think these good habits are premature optimization.
dragonwriter 6y ago
> Warnings against premature optimization suggest a two-pass strategy, where in the first pass you avoid trading increased performance for increased labor, and then in the second pass you do whatever is needed to make the performance good enough. No. The argument against premature optimization is not about labor vs. performance tradeoffs (but about correctness and maintainability vs. performance tradeoffs), nor is it about the entire code base, but about non-critical elements. Quoth Knuth: “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%.” Thinking about and designing for broad performance concerns even though it adds to initial implementation time is not against the adage; it’s when you are compromising clarity and ability to reason about the code to shave off microseconds on a path without a clear reason to believe that its going to be hit often enough that those microseconds matter in the big picture that you are engaging in premature optimization of the type targeted by the expression. EDIT: > I don’t think it’s much of a stretch to call a development paradigm that causes software to never get faster even as hardware improves “writing slow programs on purpose.” If that is its explicit intent, sure; if it is a side effect, no. In any case, blaming such a paradigm on the adage against premature optimization is misplaced.
- zamfi 6y ago
  > No. The argument against premature optimization is not about labor vs. performance tradeoffs (but about correctness and maintainability vs. performance tradeoffs), nor is it about the entire code base, but about non-critical elements. If true, I envy your ability to produce correct, maintainable code without labor!
- adrusi 6y ago
  You're right, I guess it's the cargo cult interpretation of "premature optimization is the root of all evil" that's the issue.
  - zamfi 6y ago
    That the adage was intended to address a narrower case does not invalidate your argument, friend! People should, and do, make tradeoffs for maintainability over speed — and this is still choosing to make your app slow — whether Knuth meant it or not.

by adrusi 6y ago

erik_seaberg 6y ago

Part of the reason for writing the slow version is that you need to profile it to find out where the problems actually are, because intuition is not a very good guide. Some of the worst bottlenecks seem tiny but happen so frequently they add up, while a lot of things that sounded slow don’t actually matter.

carlmr 6y ago
That's also the thing with premature. I would agree with you that premature is before you know what's slow. But if you have a CI Profiling run showing a few hotspots it's not premature anymore. Still people quote this adage. Further there are things you should know are usually performance issues, that I would expect you to avoid entirely, except with good reason. Using O(N²) or worse algorithms on big collections when there are much faster alternatives in the standard library of your language for example. I don't think these good habits are premature optimization.

dragonwriter 6y ago

> Warnings against premature optimization suggest a two-pass strategy, where in the first pass you avoid trading increased performance for increased labor, and then in the second pass you do whatever is needed to make the performance good enough. No. The argument against premature optimization is not about labor vs. performance tradeoffs (but about correctness and maintainability vs. performance tradeoffs), nor is it about the entire code base, but about non-critical elements. Quoth Knuth: “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%.” Thinking about and designing for broad performance concerns even though it adds to initial implementation time is not against the adage; it’s when you are compromising clarity and ability to reason about the code to shave off microseconds on a path without a clear reason to believe that its going to be hit often enough that those microseconds matter in the big picture that you are engaging in premature optimization of the type targeted by the expression. EDIT: > I don’t think it’s much of a stretch to call a development paradigm that causes software to never get faster even as hardware improves “writing slow programs on purpose.” If that is its explicit intent, sure; if it is a side effect, no. In any case, blaming such a paradigm on the adage against premature optimization is misplaced.

zamfi 6y ago
> No. The argument against premature optimization is not about labor vs. performance tradeoffs (but about correctness and maintainability vs. performance tradeoffs), nor is it about the entire code base, but about non-critical elements. If true, I envy your ability to produce correct, maintainable code without labor!
adrusi 6y ago
You're right, I guess it's the cargo cult interpretation of "premature optimization is the root of all evil" that's the issue.
- zamfi 6y ago
  That the adage was intended to address a narrower case does not invalidate your argument, friend! People should, and do, make tradeoffs for maintainability over speed — and this is still choosing to make your app slow — whether Knuth meant it or not.