5 Truths About Code Optimization

1) Start with working code and good tests or you are doomed.
First make it work and have good unit tests to tell you so.

2) Rest assured, you don't know where the problem is
Your best guess as to what is making this program a pig is usually wrong. The only way to know is to run your code with a profiler and see which bits are the slow ones.

3) There is always a long pole in the tent, but it is not always the same pole
Run your profiling after each change. Did my change actually help? If the change did speed things up, is there now a new bottleneck?

4) If it doesn't help, take it out
If you find out after profiling that you did not speed up, take the change out again. Despite your unit tests, every change you make risks screwing things up.
How fast is broken ?

5) You need to know when to stop
You can always think of something you can do to make the thing run a little faster, lighter, cheaper. Stop screwing up the code so that it performs better if its performance is acceptable.

These points are very obvious but in the heat of an optimisation effort you might forget one or two.

This is a summary of an excellent posting on Russ Olsen's Weblog