2

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?"

Improve this question
3
  • 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, 2011 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, 2011 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.
    – supercat
    May 13, 2014 at 1:45

3 Answers 3

Reset to default
7

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.

Improve this answer
1

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
Improve this answer
0

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.

Improve this answer
2
  • 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, 2011 at 9:31
  • That's what I wrote, didn't I?
    – user29079
    Jul 7, 2011 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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