Freetutes.com

VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

Systems Analysis - System analysis and Design tutorial for Software Engineering


You are here: Visual Basic > Advanced VB6 tutorial > Chapter 20

Results of Basic Optimization

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.

Comparative sizes of the Optimize project EXE.
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.

The Optimize application with all nodes closed except for the tests of Real Speed.
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.

Results of the string manipulation and file I/O test when compiling to P-Code.
FIGURE 20.8. Results of the string manipulation and file I/O test when compiling to P-Code.

Results of the string manipulation and file I/O test when compiling to native code optimized for speed.
FIGURE 20.9. Results of the string manipulation and file I/O test when compiling to native code optimized for speed.

Results of the string manipulation and file I/O test when compiling to native code optimized for size.
FIGURE 20.10. Results of the string manipulation and file I/O test when compiling to native code optimized for size.

Results of the string manipulation and file I/O test when compiling native code with no optimizations.
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.

Results of the code optimizations test when compiling to P-Code.
FIGURE 20.12 Results of the code optimizations test when compiling to P-Code.

Results of the code optimizations test when compiling to native code optimized for speed.
FIGURE 20.13 Results of the code optimizations test when compiling to native code optimized for speed.

Results of the code optimizations test when compiling to native code optimized for size.
FIGURE 20.14 Results of the code optimizations test when compiling to native code optimized for size.

Results of the code optimizations test when compiling to native code with no optimizations.
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.

Results of the numeric data type test when compiling to P-Code.
FIGURE 20.16 Results of the numeric data type test when compiling to P-Code.

Results of the numeric data type test when compiling to native code optimized for speed.
FIGURE 20.17. Results of the numeric data type test when compiling to native code optimized for speed.

Results of the numeric data type test when compiling to native code optimized for size.
FIGURE 20.18. Results of the numeric data type test when compiling to native code optimized for size.

Results of the numeric data type test when compiling to native code with no optimizations.
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.


  

<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © Freetutes.com | All Rights Reserved