>>The easiest way to explain this is to first understand how the runtime library works. Each command is represented by a numeric value referred to as a "token". This value represents the offset into a jump table. The jump table has the entry point into the library where the command is simulated. An interpreter has to resolve these token values, then execute the routine at runtime. When you compile a FoxPro program, however, you resolve the all tokens which are stored in the compiled output. At runtime, all that has to be done is retrieve the routine entry points. Since the process of looking up the token has already been eliminated, the result is a fastere executing program.
>>
>>This has both positive and negative effects. On the plus side, the "executable" code is generally smaller than could be produced by a native compiler. On the minus side, because it has to retrieve the entry points, it's slower.
>>
>>As a side note, the reason that macro substitution is slower is caused by the program having to resolve the tokens at runtime.
>>
>>The "p" simply stands for "precompiled".
>>
>>George
>
>Awww....now I see....
>
>
>That is excellent information, thanks.
>
>Joe

You're welcome.

BTW, for mostly Alan's benefit since he started this thread, the one of the biggest differences I've found between PowerBuilder and VFP, is that the command structure in VFP is much, much richer than PB. At least through version 4 of PB, the language was, to put it kindly, rather "spartan". This, to some degree, one of the reason that PB apps take longer. It lacks much of the functionality that we've come to take for granted.

George