Which wrong ideas are widespread for long time
There is a very widespread belief among programmers about how to find performance problems. It is that in order to find them, you have to measure them.
The simplest counter-example is an (undesired) infinite loop. It takes 100% of time, doing things that are completely unnecessary.
How do you find the problem? You get it under a debugger and pause, halt, or interrupt it. Then you look at the stack, because you know the loop is somewhere on it. You've caught it in the act. Did you measure it? or just find it?
Suppose it's not an infinite loop, it just takes longer than you think necessary.
Suppose the unnecessary work is less than 100%, like 90%, 50%, or 20%. It's the same idea. If you pause it, that percent is the chance that you will catch it in the act. (You don't have to know what the percent is to catch it.)
Just to be sure, you can pause it several times. As soon as you see it doing something, on as few as two samples, that you can replace with something faster, you can fix it for a nice speedup.
Not only that, you've just made any other problems easier to find, because the time is shorter and they take a bigger percent. This can "snowball" until the code is very close to optimal.
Of course, if you want to measure the problem, just take more samples, but that's not a prerequisite to finding it.
People tell me, wishfully, that this is what sampling profilers do but do it better. Many would rather debate the issue than see for themselves.