Practical rules for premature optimization [closed]

Answer 1

My vote goes for most people optimize what they think is the weak point, but they don't profile.

So regardless of how well you know algorithms and regardless of how well you've written your code, you don't know what else is happening outside your module. What do the APIs you've called do behind the scenes? Can you always gaurantee that the particular order of ops is the fastest?

This is what is meant by Premature Optimization. Anything that you think is an optimization that has not been rigorously tested by way of a profiler or other definitive tool (clock cycles by ops is not a bad thing, but it only tells you performance characteristics ~ actual calls is more important than timing, usually), is a premature optimization.

@k_b says it well above me, and it's what I say too. Make it right, make it simple, then profile, then tweak. Repeat as necessary.

Answer 2

What do you consider "premature optimization"? What practical rules do you use to consciously or unconsciously avoid it?

Using the Agile approach (rapid iterations with refinement of requirements through interactions with users) is helpful as the awareness that the current interface is probably going to change drastically after the next session with the users makes it easier to focus on developing the essential features of the application rather than the performance.

If not, a few iterations where you spent a lot of time optimizing a feature that was entirely discarded after the session with the user should give you the message.

Answer 3

Order of priority: 1. It has to work 2. It has to be maintainable 3. It has to be machine-efficient

That was from the first week of my first programming course. In 1982.

"Premature optimization" is any time Priority 3 has been considered before Priority 1 or 2.

Note that modern programming techniques (abstractions and interfaces) are designed to make this prioritization easier.

The one gray area: during the initial design, you do have to check that your solutions are not inherently cripplingly slow. Otherwise, don't worry about performance until you at least have some working code.

Answer 4

What practical rules do you use to consciously or unconsciously avoid it?

One way to avoid unnecessary optimization is to consider the relative cost benefit:

A) Cost for programmer to optimize code + cost to test said optimization + cost of maintaining more complex code resulting from said optimization

vs.

B) Cost to upgrade server on which software runs or simply buy another one (if scalable)

If A >> B consider whether it's the right thing to do. [Ignoring for the moment the environmental cost of B which may or may not be a concern to your organization]

This applies more generally than just to premature optimization but it can help instill in your developers a sense that spending their time doing optimization work is a cost and should not be undertaken unless there is a real measurable difference in something that actually matters like: number of servers required or customer satisfaction through improved response times.

If management can't see the benefit in reduced $ and customers can't see the benefit in better response times, ask yourself why you are doing it.

Answer 5

What is premature optimization?

Premature optimization is the process of optimizing your code (usually for performance) before you know whether or not it is worthwhile to do so. An example of premature optimization is optimizing the code before you have profiled it to find out where the performance bottleneck is. An even more extreme example of premature optimization is optimizing before you have run your program and established that it is running too slowly.

Are we at the point now where deciding between an O(n^n) and O(n!) complexity algorithm is irrelevant? What about O(n) vs O(n*n)?

It depends on the size of n and how often your code will get called.

If n is always less than 5 then the asymptotic performance is irrelevant. In this case the size of the constants will matter more. A simple O(n * n) algorithm could beat a more complicated O(n log n) algorithm for small n. Or the measurable difference could be so small that it doesn't matter.

I still think that there are too many people that spend time optimizing the 90% of code that doesn't matter instead of the 10% that does. No-one cares if some code takes 10ms instead of 1ms if that code is hardly ever called. There are times when just doing something simple that works and moving on is a good choice, even though you know that the algorithmic complexity is not optimal.

Every hour you spend optimizing rarely called code is one hour less that you can spend on adding features people actually want.

Answer 6

For some people, optimization is part of the fun of writing code, premature or not. I like to optimize, and restrain myself for the sake of legibility. The advice not to optimize so much is for the people that like to optimize.

iphone programmers in particular seem to think of avoiding premature optimization as a pro-active goal

The majority of iPhone code is UI related. There is not much need to optimize. There is a need not to choose a poor design that will result in bad performance, but once you start coding up a good design there is little need for optimization. So in that context, avoiding optimization is a reasonable goal.