First make it work, and then make it work fast!

Certainly, performance is important. Slow software frustrates users and thus is a brake for success. But instead of digging into code tuning techniques, let's just talk about the right approach for speed optimization.

Suppose we want to develop a compiler. A compiler is typically composed of 4 components: a scanner, parser, semantic analyzer and code generator/optimizer. We start by developing the scanner which reads the source code and converts it into tokens of different kinds, ignores any comments and detects syntax errors. After finishing a first working version, we look at the code and see that we could reduce the scanning time by an estimated 50%. Modifying the code will take some time and will make the code a little bit more complex, but speed counts. Should we change our code or shouldn't we? Clearly, the answer is: NO, not yet! Why not? There are several reasons:

First, before the whole compiler isn't finished, we cannot be sure that we will not do any changes to the scanner that will eliminate our speed improving modifications.

Secondly, what really counts is the overall speed of the compiler. For example, if the scanner takes only 5% of the total compilation time, then a 50% improvement of the scanner would only result in a 2.5% total improvement.

Thirdly, code tuning generally hurts other qualities like readability and maintainability. 'Clever programming tricks' should only be used if really needed and, in that case, be well documented in the source code.

Fourthly, estimating an improvement of speed is often deceptive. Until we haven't written a test and measured the time, we cannot be sure of the real gain and decide if it is worth changing the code.

Fifthly, execution speed often depends on environmental conditions. Performance data measured on our machine can be completely different on other machines or networks, because of different operating systems, compilers, virtual machines, system configurations, and so on.

Therefore, the general golden rule for code tuning is:

1. Write a correct and well designed program
2. Measure performance
3. Optimize if necessary

Of course, exceptions to the above rule are time critical applications where execution speed is imposed by the requirements. In these cases, we have to deal with performance measurements and code optimizations from the beginning on.

Consequently, optimal performance through code tuning was not an issue during early development of Obix. This concerns the source code for the compiler as well as the target code produced by the compiler. Optimization will be a last challenging task.