Jim,

>
>Periodically there is a lament that VFP *NEEDS* a compiler in order to vastly speed up its processing. Some have even claimed to be leaving VFP because of its slowness and the fact that other competing products *do* have a compiler and so are much much faster.
>
>Since I am (slowly, to be sure) getting through a first pass of the VB documentation, I came across these points (extracted only the interesting) from the VB 6.0 "Programmer's Guide" under the section title "Compiled vs. Interpreted Applications":
>
>"...In many cases, compiling to native code can provide substantial gains in speed over interpreted versions of the same application: however, this is not always the case.".
>"... For many programs, especially those doing a lot of Windows API calls, COM method calls, and string manipulation, native code will not be much faster than p-code.".
>"...Code that involves a lot of subroutine calls relative to inline procedures is unlikely to appear much faster with native code. This is becuase 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 VBA run-time functions will negate the performance benefits of native code.".
>"...I real-world tests, client applications typically spent about 5% of their total time executing p-code. Hence, if native code was instantaneous, using native code for these programs would provide at most a 5% performance improvement.".
>
>I know that this refers to VB and not VFP, but I still think it provides some valuable insight into the "problem". I know that, after reading this, I was much more comfortable that a compiler has never been high on *my* priority list.
>

This info really gives lots of readers a deep sigh of relief. It is an eye opener.

Speaking of priority list. Could you summarize your wish list for VFP improvement.