Optimisation Workflow

I believe the key to optimising any program is measurement: not writing l33t code which seems to be what a lot of programmers think optimisation is!  The optimisation process is all about finding the slow parts of your program and speeding those slow parts up by refactoring your source code to meet your target performance goals.  Without measuring the code or having target performance goals optimisation is a waste of time: as programmers are very bad at guessing where the slow parts of the program are and very good at optimising pieces of the program that do not need it.

This diagram emphasises the importance of measurement in the optimisation process: you cannot begin the process, evaluate your optimisations, even discard your optimistations or honestly finish the process without first measuring the program performance versus your target performance.  As I have mentioned before the initial optimisations to a program tend to yeild larger returns and then returns drop off until much more time is invested. These initial easy optimisations are not usually the sort of changes new programmers expect: they expect sexy l33t code like inline assembler for big performance wins, not tweaking compiler flags or removing calls to a pure virtual method on a base object in an inner loop.