This question already has an answer here:
I see the mantra of "profiling before optimization" repeated again and again here, on SO, and elsewhere. Although I certainly use profiling tools, I'm only occasionally surprised by the results. It seems like, as often as not, the profiler is just giving the same information that you could reasonably deduce by knowing the likely execution path of your program, understanding how your architecture works, and having a good idea of what optimization techniques the compiler can employ for you.
Because of this, I generally find that when I'm developing, I see areas of the code that I can sense are going to be bottlenecks (often times when writing the code I will think to myself "hey, this is going to be a critical part of the code, and needs to be fast, but I will use a slower implementation first to prove the concept, then optimize it later") and I just go ahead and optimize these areas before I bother doing much profiling.
Is this really such a bad practice, or is it just the natural result of gaining experience doing optimization?
I just wanted to point out that I do use profilers, I'm just wondering how bad it's considered to be to pick off the low hanging fruit first, rather than waiting for the profiler to prove something is slow.
Thanks for the insights so far everyone. People have posted a lot of good comments. I have to say that I still have mixed feelings about some of the advice here, but it's given me a lot of insight into why people make the statement.