4 ms·

Premature optimization has become an umbrella term for people defending poor choices during implementation. Not doing simple mistakes that kill performance for

Premature optimization has become an umbrella term for people defending poor choices during implementation. Not doing simple mistakes that kill performance for no benefit or choosing option B over A where both take equal effort but B is 20x times more performant should be common sense. Unfortunately, 9 times out of 10 I hear these often quoted phrases is when engineers defend their status quo bias during code review.

infogulch 4y ago
I like Casey Miratory's "non-pessimization" approach in Philosophies of Optimization [1] [2]. He breaks "making a program go faster" into 3 modes: (1) "optimization" which includes counting expected cycles or memory bandwidth, careful benchmarking, designing custom algorithms, etc which can be fun but is expensive and is only rarely applied; (2) "non-pessimization" which is simply avoiding adding extra unnecessary work for the cpu, which should be done 100% of the time but isn't in the industry today; (3) and "fake optimization" which is shallowly repeating 'optimization tips' and conclusions from unrelated cases of (1) without actually measuring it. [1]: https://www.youtube.com/watch?v=pgoetgxecw8 https://www.youtube.com/watch?v=pgoetgxecw8 [2]: https://www.youtube.com/watch?v=lStYLF6Us_Q https://www.youtube.com/watch?v=lStYLF6Us_Q
- neonsunset 4y ago
  Thank you for the links, looks like something definitely worth checking out, especially the name of the whole series "Simple Code, High Performance" because it sounds like the core of my approach to writing code. "non-pessimization" is my most loved technique because a design reduced to the minimum amount of necessary work and abstractions is more often than not has better performance and is easier to reason about.
  - infogulch 4y ago
    The whole series is pretty great. One of the interesting points he makes is that non-pessimization (2) is a necessary precondition to optimization (1). That any attempt to do hardcore optimization of a pessimized codebase is futile and will continuously faceplant into endless expanses of stupid code filled with unnecessary work for the cpu that instantly becomes the bottleneck.
onion2k 4y ago
Not doing simple mistakes that kill performance for no benefit or choosing option B over A where both take equal effort but B is 20x times more performant should be common sense. The full quote from Knuth is this; “The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.” In your example clearly if there are two approaches and one is 20* faster than the other it's optimization in the right place. But... it's the "at the wrong times" bit that's actually the most important part. If you have a working solution and you're spending time trying to make it faster without knowing it's too slow then you're trying to optimize at the wrong time. If you know both approaches then it's fine, and good, to pick the faster one. If you don't then you should use the one you know and come back later if you need to. Most of the time you won't need to.
Narann 4y ago
“If an implementation could be written with the same level of complexity and in the same time, with a 20x more performance, then it's this implementation that should be chosen. I'm talking about implementation choice, not optimization.” I sometime try this approach and write the better implementation in front of the dev if possible.

infogulch 4y ago

I like Casey Miratory's "non-pessimization" approach in Philosophies of Optimization [1] [2]. He breaks "making a program go faster" into 3 modes: (1) "optimization" which includes counting expected cycles or memory bandwidth, careful benchmarking, designing custom algorithms, etc which can be fun but is expensive and is only rarely applied; (2) "non-pessimization" which is simply avoiding adding extra unnecessary work for the cpu, which should be done 100% of the time but isn't in the industry today; (3) and "fake optimization" which is shallowly repeating 'optimization tips' and conclusions from unrelated cases of (1) without actually measuring it. [1]: https://www.youtube.com/watch?v=pgoetgxecw8 https://www.youtube.com/watch?v=pgoetgxecw8 [2]: https://www.youtube.com/watch?v=lStYLF6Us_Q https://www.youtube.com/watch?v=lStYLF6Us_Q

neonsunset 4y ago
Thank you for the links, looks like something definitely worth checking out, especially the name of the whole series "Simple Code, High Performance" because it sounds like the core of my approach to writing code. "non-pessimization" is my most loved technique because a design reduced to the minimum amount of necessary work and abstractions is more often than not has better performance and is easier to reason about.
- infogulch 4y ago
  The whole series is pretty great. One of the interesting points he makes is that non-pessimization (2) is a necessary precondition to optimization (1). That any attempt to do hardcore optimization of a pessimized codebase is futile and will continuously faceplant into endless expanses of stupid code filled with unnecessary work for the cpu that instantly becomes the bottleneck.

onion2k 4y ago

Not doing simple mistakes that kill performance for no benefit or choosing option B over A where both take equal effort but B is 20x times more performant should be common sense. The full quote from Knuth is this; “The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.” In your example clearly if there are two approaches and one is 20* faster than the other it's optimization in the right place. But... it's the "at the wrong times" bit that's actually the most important part. If you have a working solution and you're spending time trying to make it faster without knowing it's too slow then you're trying to optimize at the wrong time. If you know both approaches then it's fine, and good, to pick the faster one. If you don't then you should use the one you know and come back later if you need to. Most of the time you won't need to.

Narann 4y ago

“If an implementation could be written with the same level of complexity and in the same time, with a 20x more performance, then it's this implementation that should be chosen. I'm talking about implementation choice, not optimization.” I sometime try this approach and write the better implementation in front of the dev if possible.