For example, it faster on the CPU you are targeting to compare an integer to zero than to compare an integer to another integer.  Therefore you have decided to write all your loops so they count down to zero instead of the normal approach of counting up from zero.  This will save you a few cycles per iteration of your loop, but have you considered:

• Counting down and not up in a loop is not conventional in most programming languages and may result in you making math errors which can result in hard to track down bugs in your loop control logic or code inside your loop.
• Pointer arithmetic in languages like C/C++ is hard enough when counting up (e.g, pObj++) but counting down is even harder to understand as it is so incredibly rarely done and requires extra pointer math to set up.
• The programmer that comes after you to develop or maintain the source code may not realise you are counting down and not up in your loop and then implement functionality that relies on your loop counting up which would again cause bugs and confusion.
• That despite your loop being invoked for thousands or millions of iterations, your loop’s control logic is no where near as expensive in terms of CPU operations as function call X that comes right in the middle of your loop which costs millions of cycles by itself every iteration!
• That it is almost unheard of for loop control logic to be an issue performance wise even when it is in tightest inner loops.
• That most optimising compilers are perfectly able to make this optimisation for you during compilation on your target platform with none of the above programmer confusion?

My advice here is never optimise without measuring first: as at best you will save a few CPU cycles where it really does not matter at the cost of making your source more complex and harder to understand and at worse you will add subtle bugs to your program and make the source code more complex and harder to understand or maintain!  I have lost count now of how many times I’ve tracked subtle bugs in programs down to programmers making preemptive optimisations without first measuring to see if any optimisation is required and if the extra level of complexity introduced by the optimisation is a desirable trade off.

Occasionally there will be an exception to this rule but in general if you are going to optimise something should always measure first and then optimise only if it is nessessary.

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.

This may seem strange but in my experience it is true that the first few optimisation efforts on any un-optimised system tend to yeild high returns for low effort e.g, tweaking some compiler or linker settings in a few minutes.  Further medium term efforts tend to suffer from diminishing returns e.g, rewriting critical sections in assembler over a few days for a few percent improvment.  Finally large scale optimisations e.g. refactoring entire sub-systems over a week or more tends to yeild significant benefits.