Hi Jos,

>I added to my previous reply to you which is that .Net languages are not compiled to machine code either. They are compiled to MSIL code. So in that sense VFP and .Net languages are in a similar boat.

This is quite a bit misleading IMHO. The .Net gets "compiled" into MSIL and then is JIT'ed at runtime, if you don't "precompile" to machine code. My take on the general assumption on .Net "precompiling to machine code" is, that it eliminates a perf hit at app start time, but also eliminates more agressive/cpu-dependant optimization possible only to the JIT-process. Since only functions/methods actually run are JIT'ed and this approach is also used elsewhere, I guess this is not to far off base, and the best practice seems to be not to precompile, or perhaps only the parts needed up to authentication/splash screen.

VFP compiles to a pseudo-code similar to p-code, MSIL or java byte code. That p-code then is interpreted from the runtime, like the very first jvm's were doing. The speed difference to be gained from compiling to JIT machine code depended on the nature of the program, but JIT'ed java usually was 2 to 5 times faster than the first byte interpreters. OTOH, AFAIR VB6 didn't get that much of a boost by compile to machine code: I didn't research much there and have only scant "evidence" on the efficiency/working model of the VB6 compiles.

So here you are not comparing apples to apples. If you measure "simple" programming tasks like the benchmarks done in the early 80ies (sieve, sorting efficieny, array and string perf) VFP's performance is *really* not much to brag about - which is the reason of my "classifiyng" it with early java bvytecode-interpreters vs. today's JIT-techs.

OTOH you can write apps with vfp that beat the socks of apps done in those other languages: this is because one of the biggest bottlenecks is data access, and vfp is so much faster there that it can compensate for all the bad performance in other areas. Most of the "native" functions also shine (alines() for example), since they are running at c++ speed working mostly on defined memory areas (not the best description here, but I am sure you know what I am describing <g>)

And the possibility of adding really machine compiled stuff in a fll/dll keeps me from worrying too much about the perf of p-code: if there really is some numbercrunching/string massaging task which *cripples* my vfp app, I can probably redo the necessary parts in c(++) to "uncripple" it.

my 0.03 EUR (checked a bit in this area <g>)

thomas