>>>>I agree, the fox database engine with dbfs is extremely fast. It would be cool if the database engine was available in other langauges much like the Access database engine is available to C++, Visual Basic. :->
>>>
>>>
>>>Wouldn't that be great!
>>>
>>>Another extraordinarily powerful component of VFP that is often overlooked is it's macro substitution facility. You can literally write code that writes code, execute it on the fly, all within a distributed app. For *database* applications, this is super because generally you are passing a complex command to VFP's engine (thus, fast execution by the DB and GUI engines once the command processor has completed its part). However, as noted before, this aspect of VFP is equally frustrating (on the slow side) when you try to use numerically intensive algorithms in your app because VFP is an interpreted language.
>>>.
>>It's part of the price you pay for macro substitution. However, there's also another reason why numeric operations and iteration structures don't perform particularly well: the language is loosely typed. In a FOR...ENDFOR loop, depending on the terminating value, FoxPro has to manipuate up to four times the number of bytes (assuming an integer WORD) than a language that supports numeric typing.
>>
>>BTW, I've seen the remark, that VFP is an "interpreted" language. Strictly speaking, this is not correct. It's tokenized threaded pcode. Back prior to FoxBASE+ 2.0 it was a true intepreted language.
>>
>>George
>
>I have my theories, but what is the definition of 'threaded p-code'? I usually thought p-code is basically like Java byte-code in that it is post processed (compiled) data which is in turn 'interpreted' by some highly optimized loop... I wrote a simple math interpreter that used this technique, and called it 'p-code', but had no idea what the term meant.
>
>Peter

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