Hacker News Reader

Comment by ska | Hacker News Reader

Pretty verbose way of (yet again) reiterating that Knuth was essentially correct, but that many people misunderstand or misapply what he was saying. Joe says as much again in the conclusion.

To me that makes the "myth" part of the title more than a little click-baity, which is unfortunate.

Knuth is right: premature optimization is a bad idea, full stop. That doesn't mean that there aren't performance related activities you should be undertaking at various stages of implementation, that either aren't optimization, or aren't premature, or both.

View on HN

  > Knuth is right: premature optimization is a bad idea, full stop.

A bit of a "no true Scotsman" though, isn't it? Any optimization that is a good idea to do now is "not truly premature", whereas everything else is actually premature.

But that's basically every rule or guideline in the software world.

You should do X always, unless it does not make sense.

How do you know the difference ? With enough experience or enough ignorance. Knowing when you are in one category or another for a specific topic is the tricky bit.

I'm going to have to agree with ska's other comment[0] and say that it's knowing the difference between good design and optimization. Being able to design a performant system means choosing designs which are inherently fast. Squeezing the last few percent out of bubble sort makes no sense when you should have gone with, say, insertion sort in the first place.

Once you have the right algorithms, data structures, and system architecture in place and working, it's going to be fast enough and you can choose to spend time optimizing only where absolutely necessary. Even then, you should default to getting order of magnitude better performance via a better design rather than tweaking inefficiencies.

[0] https://news.ycombinator.com/item?id=11284817

I think Joe was commenting that many developers and tech leads tend to overestimate what optimization is premature and disregard appropriate forethought about performance.

Saying "this bad thing is bad" is a bit of a tautology, but there is some meaning to be gleaned from the statement.

In my experience, many developers (and tech leads) can't separate the idea of optimization from design, which is I think the core problem. But it is equally true that many of the waste inordinate amounts of time on premature or just plain misguided optimization.

How do you distinguish optimization from design?

You can't optimize a system that does not exist yet. You can't effectively optimize a system you can't measure.

Design activities allow you to think about how a system may and should behave. Optimization activities involve analysis of how a system actually behaves, and making changes typically involving performance trade offs, then analyzing those changes.

These activities can (typically should) be iterative in nature over a complicated projects development, and they do feed into each other somewhat.

What is true as a counterpoint to Knuth's maxim, is that if you do not think about the implications of your design early enough, you can easily end up painting yourself into a performance corner it may be difficult or impossible to optimize your way out of. If you've picked a fundamentally inappropriate data structure or algorithm, you may be in trouble well before you realize it. This is also why software developers would often benefit from more targeted design prototypes, earlier on.

And yes, for some of this there is no easy replacement for experience.

Another thing to think about: Optimization almost always costs you something, at the very least time, but often code maintainability, portability, generality etc. It is usually a trade-off (but not always).

Often good design work will improve your system in many respects at once.

Often by abstracting the algorithmic implementation details from the system organization and logic. Then the individual algorithms can be interchanged or modified during optimization.

There is of course some scale dependence to the use of these terms; the 'design' is of a larger system than the individual algorithms that compose it and can be abstracted and optimized.

In cases where the scale is the same, i.e. variations of the design itself will have substantial impact on its performance characteristics, then optimization and design can't be readily distinguished and Knuth's aphorism is less clearly relevant.

> many developers (and tech leads) can't separate [o]ptimization from design...."

brilliant--a few words that belongs somewhere more conspicuous.

'make it work' then 'make it fast' makes sense of course, but who wants to optimize code in quadratic time that could have been originally written w/ linear time complexity.

Reply on news.ycombinator.com