At least I will in 600 years, if my children and theirs each produce two reproducing children per generation. And that’s exactly when today’s performance optimization will pay for its own development time in CPU cycles.
I have written previously about intentionally leaving query results unordered to save some academic CPU cycles while burning money in end-user time – a poor “passive” optimization. Now we’ll discuss actively making inane optimizations that will never pay for themselves – a poor “aggressive” optimization.
A developer modifies a query with the academic goal of saving several milliseconds per execution (perhaps as few as 6 ms). If this was a query that ran thousands of times per hour during user time, we might have been able to quantify some savings to the business. Unfortunately, the optimized queries were in some procedures that run once per day during a nightly batch cycle that had no time pressure.
I ran the numbers on the CPU savings and it will take more than 600 years for the saved CPU cycles to accumulate the same amount of time spent to “optimize” the query. Because the CPU time for a batch process does not correspond to the real money being spent in user-time, this optimization will never be paid for… even in the 600 year break-even period for the CPU time.
These two types of performance optimization illustrate the danger of optimizing for purity of execution without giving any consideration to the practical implications of where our technical decisions force the business to spend its money.
No comments:
Post a Comment