Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For code review technique training, I have to cover various topics. One of them is premature optimization. I found 3 traits of it as:

  1. It's generally evil; causing inverse effects.
  2. It's an unnecessary pain, causing no gain.
  3. It demands lot of effort to achieve little benefits

Is there any other trait which am I missing ? Also, to illustrate them, I usually get a good examples for only 1st scenario. Can someone suggest any solid example for 2nd and 3rd scenario also ?

Example for 1st scenario:

Using char instead of int for smaller loops to save bytes!

for(char c = 0; c < 20; c++) {} //Evil: Accessing 'char' costlier than 'int'

[Note: I am not worried about the fact that compilers usually itself takes care of premature stuff. This training is meant just for illustration.]

This question is not about, "What optimizations are premature?"

share|improve this question
2  
All those three traits seem to be the same thing: Cost for no Benefit. Indeed, all premature optimization is simply cost without benefit. Wait other bad "traits" can possibly exist? –  S.Lott Jul 7 '11 at 11:05
    
The problem is, premature optimization is often in the eye of the beholder. Some people will complain about i++ vs. ++i, but will call it "good design" to throw in hash tables everywhere, back pointers, and deep notifications. IMHO those are both premature optimization. –  Mike Dunlavey Jul 8 '11 at 2:15
add comment

3 Answers

Premature optimization:

  1. Is based on unmeasured, hypothetical performance, and
  2. Is used as an excuse for poor application design.

The first point says that optimizations for performance should be based on profiled code, so that you can focus on the hot spots and get the most bang for your buck.

The second point says that you should not throw away all optimizations at the beginning, just because you think they are premature. The so called "evil" of premature optimization is not an excuse for ignoring performance completely until your application is finished. If you do that, you may find that your design doesn't scale, and you'll have to rewrite significant portions of it.

Choosing the appropriate data structures for your program is an example of early performance optimization that is not only desirable, it is necessary. Good design is never premature.

share|improve this answer
add comment

Most importantly, optimizations most often makes the code far less readable. Optimizing when there is no need to optimize certainly counts as premature. Optimizations should only be made when the code is done and when there is a need for them. As a rule of thumb, the author should be able to motivate why it was necessary to do a certain optimization, and do so in the source code comments.

Among the most ugly premature optimizations you will find function-like macros, file scope variables declared there only for the sake of speed, peculiar obfuscated loops (counting backwards is one example), moving all code to a h-file so that it can be inlined etc.

Unless of course, the optimization does not make the code less readable. One such example is passing structs/objects by reference instead of by value. This optimization does not make the code less readable, because it is incredibly common and will not confuse the reader. The reader would however most likely frown if you passed it by value, they expect you to do this optimization or otherwise they will regard your program as poorly written.

share|improve this answer
    
There's no reason an optimization has to make the code less readable. Also, look at Robert's answer to see that ignoring performance is not premature. –  edA-qa mort-ora-y Jul 7 '11 at 9:31
    
That's what I wrote, didn't I? –  user29079 Jul 7 '11 at 18:18
add comment

Premature optimization is often:

  • Micro-optimization. Optimizing on the lowest level. Focusing on the (irrelevant) details of implementation at the cost of design. E.g. optimizing the inner loop, instead of designing an algorithm without the loop.
  • Done before code is working, and so breaking the golden rule of: Make it work. Make it right. Make it fast.
  • Sprinkled with frivolous special cases
  • Adding entities or concepts without necessity, and so violating Occam's razor
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.