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

Interpreted Code

In an interpreted language, each individual language statement is converted to machine code on a line-by-line basis. A line is read and translated into machine code. The computer then reads the machine code for that line and executes its instructions. Then the next line is read, translated, and executed, and so on for every line in the source code.

Because this process must be repeated every time the program runs, interpreted languages are generally rather slow. The source code can be saved for re-use, but it must be re-interpreted every time the program runs.

If you have an old version of MS-DOS or PC-DOS, you probably have an example of an interpreted language. The GW-BASIC and BASICA implementations of BASIC that were included with DOS each provided an interpreted environment for running BASIC commands and programs. You could type a line of code and see just what effect it would produce before typing the next line. Despite the slow speed of execution, the real strength of an interpreted language is this capability to interactively test and debug portions of code within the development environment at any time.

A compiled program is executed differently than an interpreted program. When a program is compiled, the entire program is read and translated into machine code prior to execution. The translation from high-level language into machine code occurs just once, and the translation is saved for re-use. Because there is no overhead for the concurrent translation that occurs with an interpreter, programs produced in compiled languages generally execute faster than those produced in interpreted languages.

The speed at which one’s code executes isn’t always the defining characteristic of an application’s speed at runtime, however. If an application is internally responsible for a lot of processing—for instance, if it performs complex mathematical calculations, or processes lengthy loops or large arrays—it certainly will benefit from compilation.

If an application depends on external resources—say, the speed at which a remote database searches and sorts its records—the benefits of compilation will be less apparent, as its internal code execution is less of a factor in the performance of the application as a whole. If it takes several seconds to return records from a remote database in Cleveland, it doesn’t matter so much to the person running your program in Cincinnati that compilation to native code cut the time required to build the SQL statement by a few hundredths of a second.

Until the release of version 5.0, Visual Basic did not compile to native code, but it didn’t depend on an interpreter, either. Instead, it produced P-Code, which stands somewhere in between.

NOTE - Creation and Destruction of Object Files: Ordinarily, you won’t find OBJ files in your Visual Basic project directories. That’s because VB cleans up after itself after it produces your executable file, DLL, or custom control. It still creates object files, but it deletes them after the link step. If you find an OBJ file in a VB project directory, it may be left over from an earlier attempt to compile the project that was disrupted.

If you are curious to see what usually happens to these object files, run Explorer in a window behind VB. Make sure that you have your project directory displayed in Explorer, and then compile a VB project. You can watch as the object files are created and destroyed just before the end product of your project is produced.


<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved