Optimizing for Small Code
Selecting the second button causes the compiler to minimize the size of the
code it produces. You can easily guess the trade-off between the speed and size
optimizations. If selecting fast code produces speed at the expense of a larger
EXE, selecting small code may generate a more compact file at the expense of performance.
As you have already seen, a shorter list of instructions doesn’t necessarily
correlate with greater performance.
No Optimization
If you select the third button, the compiler still generates native code, but
it will no longer be optimized. Before you decide that Microsoft was asleep at
the switch when this option was released, think about what it takes to develop
an optimizing compiler. It isn’t easy to determine precisely how to handle
every conceivable combination of factors governing the use of an optimization.
Detecting when it is safe to move an instruction out of a loop or when a particular
register value ought to be retained is no mean feat, and it is possible that the
optimizer may make a mistake.
In other words, the opportunity to optimize one’s code is also another
opportunity to introduce a bug. Generally speaking, it is certainly possible to
introduce a bug via an optimization switch. The initial release of Visual C++
5.0 had some problems with its speed optimizations, for example. (The problem
was quickly identified and remedied with a service pack.)
Optimized or not, native code still ought to execute faster than P-Code. If
you find that your program doesn’t run properly when you compile it with
optimization features activated, you should try compiling with no optimization.
If your program still misbehaves, it is probably not the fault of the compiler—this
bug belongs to you! If the program behaves properly after being compiled with
no optimization, however, it is just possible that you have found a bug in the
VB6 optimization routines.
