Compiled vs. Interpreted Applications

By default, applications created in Visual Basic are compiled as interpreted or p-code executables. At run time, the instructions in the executables are translated or interpreted by a run-time dynamic-link library (DLL). The Professional and Enterprise editions of Visual Basic include the option to compile a native code .exe. In many cases, compiling to native code can provide substantial gains in speed over the interpreted versions of the same application; however, this is not always the case. The following are some general guidelines regarding native-code compilation.

• Code that does a lot of primitive operations on hard-typed, nonstring variables will yield a maximum ratio of generated native code to displaced p-code operations. Complex financial calculations or fractal generation, therefore, would benefit from native code.
  
  
• Computationally intensive programs, or programs that shuffle a lot of bits and bytes around within local data structures, will gain very visibly with native code.
  
  
• For many programs, especially those doing a lot of Windows API calls, COM method calls, and string manipulations, native code will not be much faster than p-code.
  
  
• Applications that consist primarily of functions from the Visual Basic for Applications run-time library are not going to see much if any advantage from native code, because the code in the Visual Basic for Applications run-time library is already highly optimized.
  
  
• Code that involves a lot of subroutine calls relative to inline procedures is also unlikely to appear much faster with native code. This is because all the work of setting up stack frames, initializing variables, and cleaning up on exit takes the same time with both the p-code engine and generated native code.

Note that any calls to objects, DLLs or Visual Basic for Applications run-time functions will negate the performance benefits of native code. This is because relatively little time is spent executing code — the majority of time (usually around 90–95%) is spent inside forms, data objects, Windows .dlls, or the Visual Basic for Applications run time, including intrinsic string and variant handling.

In real-world tests, client applications typically spent about 5% of their total execution time executing the p-code. Hence, if native code was instantaneous, using native code for these programs would provide at most a 5% performance improvement.

What native code does is to enable programmers to write snippets of code or computationally intensive algorithms in Basic that were never possible before because of performance issues. Enabling these "snippets" to run much faster can also improve the responsiveness of certain portions of an application, which improves the perceived performance of the overall application.

For More Information   To learn more about native-code compilation, see "Compiling Your Project to Native Code" in "More About Programming."