For most code, you don't know how fast it "ought to" be, so you don't even know there is a problem. Most people discover there is a problem only when somebody comes up with a faster program. Then, your program you thought was fast
instantly becomes slow.
So, in general it is best to just assume there is a problem, and that the program really ought to be running 2x or 10x faster. Then, discover why it isn't, and what must be done to get it there. Often enough, having got to 2x, a new bottleneck is slowing it down, and you may start over and get out another 2x. And again.
Sometimes it is best to release your intermediate improvements, and space them out a ways; three 2x releases can be much better for your reputation than a single 8x release, and no more work.
Also, sometimes clearing a bottleneck (apparently) doesn't end up helping, because you have just lurched from one bottleneck to another. Don't be discouraged by this: it's normal. You're digging a ditch across an oxbow, and halfway doesn't help anybody. You just need to keep digging. When you get there, the flow takes off, and you are a magician.
So, in general it is best to just assume there is a problem, and that the program really ought to be running 2x or 10x faster. Then, discover why it isn't, and what must be done to get it there. Often enough, having got to 2x, a new bottleneck is slowing it down, and you may start over and get out another 2x. And again.
Sometimes it is best to release your intermediate improvements, and space them out a ways; three 2x releases can be much better for your reputation than a single 8x release, and no more work.
Also, sometimes clearing a bottleneck (apparently) doesn't end up helping, because you have just lurched from one bottleneck to another. Don't be discouraged by this: it's normal. You're digging a ditch across an oxbow, and halfway doesn't help anybody. You just need to keep digging. When you get there, the flow takes off, and you are a magician.