Step 1: Don't do it.

The first goal should be to make your program operate correctly. A right answer 5 milliseconds too late may be wrong, but a wrong answer on time is still wrong.

Make sure your program produces the right answer - worry about how fast it is after you know you are able to finish the race at all.

You can also make some gains by using the other interpretation of "Don't do it" - remove code. Even a single instruction is slower than doing nothing at all, so if you don't need to do it, then don't do it.

Step 2: Don't do it yet.

There is also little point in spending a lot of effort hand-tuning a piece of code that runs for 1 minute once a week to produce a result that is not needed until the next day. That same effort would be a good investment if the piece of code runs every 2 minutes, or if the results must be available after 50 seconds.

Profile your code to determine which parts are just not fast enough, and which parts would provide the biggest payoff if they were faster.

Once again, "Don't do it yet" can be interpreted differently, restructuring your code to delay non-critical operations can improve the performance of critical sections.

Step 3: Don't do it that way.

Now that you have a program which produces the right answers but just a bit too slow, and you know which parts will have most effect if made faster, you can look at how those parts do what they do. In general, bigger improvements can be reaped by using more efficient algorithms than by lower level optimizations.

Step 4: Let the machine do it.

Most modern compilers (including ours) have had a lot of effort put into their optimizer passes. Most optimizing involves detailed cross-referencing and comparisons, and computers are generally much better at doing this consistently and correctly than humans are. Turn on as many aggressive optimizations as you choose, but be sure to note any warnings the compiler gives you about questionable constructs. In fact, turn up the warning level first, to ensure you are aware of any such issues before they become a concern. Some things are explicitly left undefined by the C language standard to avoid limiting options the compiler might have for generating code - which might be in some ways "better", and the compiler is free to treat such constructs differently at any time.

Step 5: OK, do it.

If you have followed all the above steps and are still determined to hand-optimize your code, it is a good idea to verify after you have done it and that it has actually had a positive effect. Look at the assembly list file produced by the compiler after each "improvement" (and re-profile the code) to be sure that you know the change has been beneficial. If you cannot prove that it helps, don't do it.

If you know of a more efficient method to do things, please feel free to forward it onto our development team at support@htsoft.com. You never know, the method may just as well be incorporated into the next version of our optimizer, which in turn means that it can be applied automatically to all of your future programs, and to all other users', without any further effort from yourself.