Use the sample Optimize project included with VB. The project file is named
Optimize.VBP. Assuming that you installed the sample files and that you used the
default directory structure when you installed VB, you will find the Optimize
project in the \VB\Samples\Pguide\ Optimize directory.
The Optimize project is particularly appropriate here because it assesses the
speed at which certain VB operations run. The point of the "Real Speed"
portion of the project is to show you how to write more efficient routines for
string and file manipulation, variable access, and numeric data processing.
You will use the Real Speed tests from the Optimize project to assess the relative
impact of VB6’s basic optimization scheme in these areas. All you need to
do is compile the project four times, producing a separate EXE corresponding to
each of the basic options: one EXE each for P-Code, native code optimized for
speed, native code optimized for size, and native code with no optimization.
Before you measure performance, take a look at the size of the EXE produced
by each option, as shown in Figure 20.6.
FIGURE 20.6 Comparative sizes of the Optimize project EXE.
The P-Code EXE is smallest, and native code with no optimization is largest.
Optimizing for speed doesn’t produce a file much larger than optimizing
for size. Considering the total size of the files necessary to distribute the
application, there isn’t really a great size difference among the four files.
This suggests that compiling for fast performance may be worthwhile as a matter
of course. In any case, the price of speed doesn’t seem to result in a large
enough size penalty to worry about unless you are extremely pressed for disk space.
When you run the Optimize project, its main form looks something like Figure 20.7.
FIGURE 20.7 The Optimize application with all nodes closed except for the
tests of Real Speed.
The first test shows how to improve the performance of string manipulation
and file I/O. (Strings are built more efficiently outside a loop, and binary file
access is faster than random file access.) You shouldn’t see any deviation
from these general conclusions in your comparison of the four EXE files, but you
ought to learn something about the effect of the basic optimizations on string
manipulation and file I/O. Because you are working from the same code base and
running the tests on a single machine (in the author’s case, a Compaq DeskPro
SP with 64MB RAM running Windows NT Server 4), any significant differences in
the timings assessed by the Optimize project can be attributed to the optimizations
introduced by the VB6 compiler.
Figures 20.8, 20.9, 20.10, and 20.11 show the results of the string manipulation
and file I/O tests.
FIGURE 20.8. Results of the string manipulation and file I/O test when compiling
to P-Code.
FIGURE 20.9. Results of the string manipulation and file I/O test when compiling
to native code optimized for speed.
FIGURE 20.10. Results of the string manipulation and file I/O test when compiling
to native code optimized for size.
FIGURE 20.11 Results of the string manipulation and file I/O test when compiling
native code with no optimizations.
Depending on your machine, you may want to specify a different number of iterations
than the 100,000 string operations and 10,000 file operations used here. The goal
is to run enough iterations to discern measurable differences among the behaviors
of each optimization choice.
What conclusions can you draw here? In these tests, it looks as if there isn’t
a great deal of difference among the results for each optimization type. Because
the measurements are all fairly close, even for P-Code, perhaps this merely indicates
that the string manipulation code in the VB runtime is already pretty well optimized.
The close timings on the file I/O tests are a reminder that other factors besides
native code influence performance. No matter how fast the code executes in memory,
you still depend on a hard drive (the fastest of which is still relatively slow
compared to memory and processor throughput) for accessing data files.
The second test should be more instructive (see Figures 20.12, 20.13, 20.14,
20.15). As its name implies, the code optimization test is more a measure of how
VB handles its own code. It is a test of internal factors that shouldn’t
be influenced either by runtime libraries that have been optimized in advance
or by the speed of a physical device.
FIGURE 20.12 Results of the code optimizations test when compiling to P-Code.
FIGURE 20.13 Results of the code optimizations test when compiling to native
code optimized for speed.
FIGURE 20.14 Results of the code optimizations test when compiling to native
code optimized for size.
FIGURE 20.15 Results of the code optimizations test when compiling to native
code with no optimizations.
In every test here, you clearly see that P-Code is slowest and optimizing for
speed is fastest. The single biggest difference is in the handling of Variant
data types, which native code does much more efficiently than P-Code. On the whole,
it looks as if optimizing certainly makes a difference, although it doesn’t
make much difference whether one optimizes for speed or size; both are generally
faster than P-Code or unoptimized native code.
The final test enables you to explore performance with numeric data types.
The differences here are striking even over a small number of iterations, as shown
in Figure 20.16, 20.17, 20.18, and 20.19.
FIGURE 20.16 Results of the numeric data type test when compiling to P-Code.
FIGURE 20.17. Results of the numeric data type test when compiling to native
code optimized for speed.
FIGURE 20.18. Results of the numeric data type test when compiling to native
code optimized for size.
FIGURE 20.19 Results of the numeric data type test when compiling to native
code with no optimizations.
Again, P-Code is slowest by a big margin in every test. Either optimization
is an improvement on unoptimized native code. But once again, there doesn’t
seem to be a great deal to recommend optimizing for speed over optimizing for
size; both seem to execute at fairly similar speeds.
On the whole, it looks as if some real performance benefits are available through
the basic optimizations. The next section covers the advanced optimizations.
