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.
