Optimization is premature if:
-
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.)
-
You’re doing something time-critical in something other than assembly, and still worrying whether
i++; i++;
is faster ori += 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.) -
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 orEnvironment.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. 🙂