Tell HN: Optimization is only premature when the expected profit is negative
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.
9 comments
[ 3.1 ms ] story [ 30.3 ms ] threadOP'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.
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.
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.
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.