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.LottJul 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 DunlaveyJul 8 '11 at 2:15

Using an unsigned char rather than an int is often a good idea in the particular case where one is coding for an 8-bit embedded processor. On an 8051, do{...} while(--someByte) will compile the loop branch to DJNZ someByte,branchTarget (three bytes; two cycles). Using an int would yield something more like mov a,someInt+1 / add a,#255 / mov someInt+1,a / mov a,someInt / adc a,#255 / mov someInt,a / orl a,someInt+1 / jnz loopTarget. About nine cycles. Not exactly a "small" optimization.
–
supercatMay 13 '14 at 1:45

3 Answers
3

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.

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.

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.