>>Native code? What for?
>
>Not for anything we do with VFP. In the old days, we had to squeeze every bit of performance out of our applications so they could run decently on 10 or 16 Mhz PCs. Native code gave us that edge. Today, all the points you mentioned make p-code the winner, unless you are writing an OS, or the next Quake.

Exactly my point. I remember CP/M and Sinclair Spectrum, the many ways you can write a constant to save a byte or two; I remember even packing .dbf date fields into two-byte strings (indexable!) just to save space - but nowadays, spending hours to squeeze few megabytes is nonsense. Calculate your time and the megabytes involved. The same goes for the time gained in "interpreted" (I'd rather say "compiled on the fly") environment like VFP versus the time you spend compiling/linking/testing for a doubtful gain of speed.

Besides, more horrific speed issues can be addressed to bad programming than to p-code being slower than native. No super-ultra-turbo-zip-bang-top-speed native code can save a bad approach to the problem.