VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

VB .NET - Learn Visual Basic .NET

Systems Analysis - System analysis and Design tutorial for Software Engineering

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

Compiling to P-Code

Yes, P-Code is still a compiler option. After you have loaded a project and are ready to produce an EXE, your File menu might look like Figure 20.1.

When you choose Make, you will see another dialog box that enables you to set various compiler options. To instruct the compiler to produce a P-Code EXE, all you need to do is select the P-Code option from the dialog box, as shown in Figure 20.2.

The menu command to produce your EXE file.
FIGURE 20.1 The menu command to produce your EXE file.

Setting compiler preferences at compile time.
FIGURE 20.2. Setting compiler preferences at compile time.

If you want to set your compiler options, but you aren’t yet ready to compile to an EXE, you can also reach the compiler properties by pulling down the Project menu and choosing Optimize Properties. It looks like Figure 20.3.

Setting compiler preferences from the Project menu.
FIGURE 20.3 Setting compiler preferences from the Project menu.

You will work from the Project menu for the rest of this chapter. Notice that the Project Properties window, as shown in Figure 20.4, has two additional tabs that don’t appear on the dialog box you get when you choose Make from the File menu. Because you are only concerned about setting compiler options now, the extra tabs don’t matter.

The Project Properties dialog box uses four tabs to set project options.
FIGURE 20.4 The Project Properties dialog box uses four tabs to set project options.

When you select the Compile To P-Code option button, the other controls on the dialog box are disabled. That’s because the other controls set optimization preferences, and P-Code doesn’t get optimized in VB6. The EXE generated on compilation behaves just like the P-Code EXEs from earlier versions of VB.

If the capability to compile to native machine code is such a big deal, why does Visual Basic 6 enable you to choose not to take advantage of this great new feature? After all, if native code always executes faster, why would you ever want to bother with P-Code any more? Three reasons come to mind.

First, speed isn’t everything. Because it doesn’t have to bundle all the native machine code into the EXE (remember that with a P-Code EXE, the runtime file contains the native routines), compiling to P-Code produces smaller EXE files. The advantage of this smaller footprint increases as multiple VB applications are deployed on a single computer.

Theoretically, this can be a compelling factor in favor of P-Code, especially on a computer with a relatively small hard drive. In practice, however, this was more of an advantage for Visual Basic versions 3.0 and earlier, when the runtime files weren’t nearly as big as they are now. The VB3 runtime file (VBRUN300.DLL) is about 390KB. The VB4 runtime files take up about 700KB. With VB6, the least you can get away with is about 1.3MB.

With the growth of the runtime files, the size of the EXE itself has become a proportionately less significant factor in distributing applications. Still, the runtime files need to be installed just once to support any number of applications. Therefore, generating a smaller P-Code EXE may still be important to those running short of disk space.

A second reason why P-Code is still an option may be because the native code speed advantage isn’t always a huge factor. The degree to which P-Code incurs a performance hit depends on the granularity of the interpreted routines. If even the slightest action entails a call to the interpreter, the slowdown could be immense.

Fortunately, however, the VB P-Code system has evolved to the point that it uses many fairly large-scale instructions, each of which is executed by a big compiled subroutine. VB’s built-in functions fall into this category, for instance. (Although some, such as IIF(), are still notoriously slow. Given the speed of the C/C++ ternary operator that IIF() emulates, this is surprising.) After they have been passed to the runtime files, these subroutines run at native speed, so the P-Code overhead need not be substantial.

Third and finally, a P-Code engine certainly simplifies the distribution of common features among multiple programs. Why do you suppose Microsoft settled on this mechanism for building macro and programming capabilities into so many of its applications via Visual Basic for Applications? A native compiler for VBA would certainly have been interesting, but the convenience of the P-Code engine is compelling, especially when you consider that Microsoft applications such as Word and Excel need to run on Apple platforms in addition to Windows.


<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved