|Perl: the Markov chain saw|
Re: CPU cycles DO NOT MATTER!by radiantmatrix (Parson)
|on Apr 21, 2008 at 16:40 UTC||Need Help??|
If we're confining ourselves to optimizations that make a very small difference per-operation, then I'd generally agree that the vast majority of the time1, the CPU time doesn't matter.
On the other hand, the core of your argument is somewhat specious:
Anything you do needs to be measured in that light by the person paying you. Is it worth having my person spend 3 days here and 2 days there squeezing out performance? Or, is it worth just buying another machine and having my person actually spend time advancing my business? Because, there's an additional opportunity cost to squeezing performance cause you're not doing something else that actually makes money.
When you talk about lost opportunity cost, etc., you miss a major piece of the puzzle -- it might take me 3 days to find the best algorithm to use (and get it working), but that effort has zero ongoing cost. In fact, I can use what I learned the next time there's a related problem, and I won't be spending that same 3 days again.
However, adding a new server does have ongoing costs. You have to admin it, secure it, keep its software up to date. You also have to plan to replace it when it breaks or ages.
Choosing when and what to optimize is extremely complicated. I tend to agree with the Two Rules of Optimization (I think these are Knuth's?):
So, if I were to rephrase your advice, I might say this: don't worry about optimizing your code until it works, and even then only if there is really a performance problem. I may even add that sometimes adding resources2 is a better solution than optimizing code -- but I disagree that it's always a better solution.
Beware false absolutes.