Tell HN: Optimization is only premature when the expected profit is negative | Hacker News Reader

Tell HN: Optimization is only premature when the expected profit is negative

4 pointspc2g4d8 comments

Many optimizations are dismissed as irrelevant and "premature". But, for enterprises with finite cash to throw at hardware, fewer optimizations are premature than is often assumed.

Use less memory, use less CPU, and you can get more instances running on a single machine.

RiiR, switch to a unikernel, etc. same thing.

But only real optimization counts---real reductions in resource usage. Not things you believe _should_ make things faster or lighter; only things that _do_.

But if the optimization costs you more in developer time than will be reclaimed in operations costs over the _entire lifetime of the code_... then it is premature.

Estimating this, though, is a challenge.

Just stating the obvious, I suppose.

View on HN

Optimized code takes longer to write and is often more complex and less readable and less maintainable. Since software engineer salaries costs are higher than hardware costs it would take way longer and cost more to optimize all code.

When you're writing code sometimes you need to refactor, requirements change etc.

You may focus on optimizing code for saving 3 nanoseconds on code that doesn't run that often.

Optimization is important, and can save money on hardware resources, but focusing on the wrong things to optimize can be costly and make the application more difficult to maintain.

Once you identify the bottlenecks of the application you can focus on optimizing these.

Obviously that doesn't mean you should throw away resources, so it's always a good idea to use static analysis in combination with code reviews to avoid unnecessary use of resources, like repeatedly doing a costly operation in a loop that always yields the same result (it can be done before the loop starts, or you can memoize/cache the result to reuse it), caching network/database requests that are expected to return the same data, use a connection pool for expensive resources like database connections...

But more advanced optimization should be reserved for bottlenecks.

It could be argued that refactoring is a form of optimization, you are just optimizing for maintainability of the code base rather than performance - in which case we should always be looking to optimize our code :)

The problem with skipping major optimizations is that the tech debt grows with time.

The ROI calculation is tough, but there are things the simply make sense by looking at the data, e.g. find underutilized resources based on the native tools in the cloud infrastructure environment.

That only gets you to a local minima. The point of avoiding premature optimization is to avoid optimizations that you've done making things too complex for you to be able to get to global minima for the problem your code is solving.

No, because there is also opportunity cost to consider.

Sorry, I must be missing something as I can't see what you're saying that's different to don't optimize prematurely.

"Don't optimise prematurely" is not great advice, because it's tautological. "Premature" optimisation is obviously bad, otherwise it wouldn't be "premature"! The hard part is knowing when an optimisation is "premature", and that statement on its own doesn't give you anything to work with.

OP's advice is a little bit better, since at least it gives you a starting point for evaluating whether a certain optimisation is worth doing, i.e. looking at it through the cost vs the benefit.

I just felt that they were trying to say more than the obvious and I had missed what they were getting at.

Personally I don't encounter usually encounter "Don't optimize prematurely" being used as a stand alone statement. When it's being given as advice then it's backed up with examples of when an optimization is premature and when it's a good time to optimize.

The few times I do encounter it variations of it being used a statement is in code reviews, but then you've got the context of the code being commented on to help understand what the reviewer is getting at.

Reply on news.ycombinator.com