solegaonkar:

If you're not measuring, then you're guessing.

If you're guessing, you're doing it wrong.

Example: If you take a function and make it take half the time, but your program only spends 1% of its time in that function, you've saved 0.5%. Not terribly significant. On the other hand, If you take a different function and make it take half the time, and your program spends 50% of its time in that function, then you've saved 25%. Much better!

So first figure out where your program is spending all its time. Then look at that area and see what you can do to speed it up. Frequently, programs spend most of their time in a very small part of the code, so there's no real benefit in optimizing "everything".

Changing your program everywhere to get a small gain will get you: (a) a small gain, and (b) many chances to introduce errors.

Also, as others have mentioned, you'll often get a *much* higher payoff by finding a better way to do it (algorithm) than polishing what you have a little here and there.

Finally: It's easy enough to go down the rabbit hole and make the code faster than it needs to be. Obviously, faster is better. But spending too much time to make it faster can rob your project of time needed for other tasks. So before you start optimizing, figure out how fast is fast enough. Then when your code hits the benchmark, stop. Otherwise, you may have a very fast, but uselessly late bit of code.

...roboticus

When your only tool is a hammer, all problems look like your thumb.