Neil,

>I don't understand how interpreting then executing can be faster than native execution, please explain?


Interpretated languages:
- First interpretate the P-CODE
- Then Execute the internal C/C++ code.

Native code:
- Execute the internal C/C++ code right away


I didn't say that P-CODE is faster. I said that the difference is relatively so small that native code would not be significant faster. For example if the Interpreter needs about 1 millisecond to interpretate a SQL SELECT command and it takes about 10 seconds to execute the query (in the underlying C/C++ code) then compiling it to native code would give you a speed increase of 0.01 %. Not exactly my idea of boosting performance. The speed of many VFP commands are determined by I/O in which the I/O is taking a considerable % of the time needed to execute the command (for example USE, SQL SELECT, REPLACE, SEEK, LOCATE ? SHOW WINDOW, .Refresh, CLOSE etc)

AFAIK, Interpreting the command is almost never the bottleneck in performance. OTOH I/O is.

>>> As for commands that don't rely that much on I/O, they could be faster if
>>> compiled native code, but I doubt if that would be that much. Remember we've
>>> got very fast string manipulation which is comparable to native compiled
>>> code.
>
>Wasn't their a comparison/test over at DevX on string manipulation in languages? Again if there was no real benifit in compilation to native code why do it? The new CLR has JIT compilers that convert the IL to native code? Why does Microsoft spend thousands of dollars in compiler development?

I've got no source to back this up, but I believe there was a MS statement (I think I read it at fox-wiki) that on the whole native compiled code was less than 5% faster than interpretated code in an avarage application. In the early days when we didn't have the fast computers we have now, and the P-CODE technologie was not as advanced, interpreting the P-CODE took a considerable % of CPU resources. The number of CPU cycles to interpretate the code have not changed much (this is depended on the richness of the language) but nowerdays we have lots more CPU cycles in a second. IOW the time that the interpretator needs to execute becomes less important (In comparison to I/O).

The difference between P-CODE and native code is most clear in simple commands like:

A = 1
A = A +1
A = A * B / C 

OTOH in the following more complex commands it is not likely you'll note the difference

REPLACE ALL Amount WITH AmountNextYear FOR Sex = "F"
SELECT * FROM a INNER JOIN B on a.x= b.x INTO CURSOR Y

The point is that in the first one the execution of the C/C++ code is faster than that of the P-CODE interpreter, In the second one the time to translate the P-CODE is nothing compared to the internal C/C++ code which is run after that.

>>> The speed of my application are mostly determined by I/O, so I won't expect
>>> very much speed enhancement with a native compiler.

>So your software has no analytic functions, logic, control statements or interface?

Of course, but they seldom are the bottleneck in performance. The bottlenecks I frequently encounter are:
- Speed of graphical display functions (determined by CPU and Video card).
- Speed of Disk I/O and or Network (Network architecture, Disk performance, CPU)

These are issue that are not caused by the interpreter. Even the non windows standard GUI in VFP has nothing to do with the interpreter. The bug of slow forms when having many objects on it, neither has to do with the interpretator (or at least should not).

>>> You don't have to. When reading the ASCII and comparing this with a FPW 2.6
>>> app, you come to this conclusion real fast.
>
>How can you draw this conclusion by viewing the P-Code through Notepad? Can you categorically say that you understand what its composed of? I am not on the VFP development team so I can't but again their are design tradeoffs, speed VS size etc.

I sure can't read the P-CODE, but in my perception comment lines should not be included in an Exe. In Fpw 2.6 you could include debug info, but it was fairly compressed. In VFP the sourcecode with comments indentation etc is all included in the EXE file. Properties are set in ASCII text, etc.. This is not my idea of having tight compiled code (even with debug info)

>>> Well, I read some story about one exe containing several megs of debuging
>>> info because of commenting you're code. Developers should not be punished
>>> for commenting code. Well it is not up to me to decided how the VFP team
>>> would spend its time. Everyone has other priorities. Personally I like to
>>> see that the VFP team expands its compiling options....
>
>In debug builds granted but IMHO that's okay. Go build yourself a debug and release DLL in Visual C++ and look at the differences in size and speed? How are you being punished by including comments in the DEBUG versions of your code?

Most of my applications are released with debug code, because if a client has a problem I need the linenumber on which the error occured. Life would be easier if VFP was able to determine the lineno without the debug info in it.

Walter,