When is optimization premature? [closed]

Question

I see this term used a lot but I feel like most people use it out of laziness or ignorance. For instance, I was reading this article:

http://blogs.msdn.com/b/ricom/archive/2006/09/07/745085.aspx

where he talks about his decisions he makes to implement the types necessary for his app.

If it was me, talking about these for code that we need to write, other programmers would think either:

1. I am thinking way too much ahead when there is nothing and thus prematurely optimizing.
2. Over-thinking insignificant details when there is no slowdowns or performance problems experienced.

or both.

and would suggest to just implement it and not worry about these until they become a problem.

Which is more preferential?

How to make the differentiation between premature optimization vs informed decision making for a performance critical application before any implementation is done?

Answer 1

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. :)

Answer 2

This proverb does not (I believe) refer to optimizations that are built into a good design as it is created. It refers to tasks specifically targeted at performance, which otherwise would not be undertaken.

This kind of optimization does not "become" premature, according to the common wisdom — it is guilty until proven innocent.