When is optimization premature? [closed]

Optimization is premature if:

  1. Your application isn’t doing anything time-critical. (Which means, if you’re writing a program that adds up 500 numbers in a file, the word “optimization” shouldn’t even pop into your brain, since all it’ll do is waste your time.)

  2. You’re doing something time-critical in something other than assembly, and still worrying whether i++; i++; is faster or i += 2… if it’s really that critical, you’d be working in assembly and not wasting time worrying about this. (Even then, this particular example most likely won’t matter.)

  3. You have a hunch that one thing might be a bit faster than the other, but you need to look it up. For example, if something is bugging you about whether StopWatch is faster or Environment.TickCount, it’s premature optimization, since if the difference was bigger, you’d probably be more sure and wouldn’t need to look it up.

If you have a guess that something might be slow but you’re not too sure, just put a //NOTE: Performance? comment, and if you later run into bottlenecks, check such places in your code. I personally don’t worry about optimizations that aren’t too obvious; I just use a profiler later, if I need to.

Another technique:

I just run my program, randomly break into it with the debugger, and see where it stopped — wherever it stops is likely a bottleneck, and the more often it stops there, the worse the bottleneck. It works almost like magic. 🙂

Leave a Comment