>>>Hi to all who are interested in this topic.
>>>
>>>One of my customers has a colleague who states that the application that I've written should be written in C++, which would give a better performance. I wonder whether he's right and if not, what arguments I could use.
>>>
>>>The core of the app hardly uses DBMS functions. Instead, it uses low-level functions like FOPEN(), FGETS() and FPUTS(), and string manipulation functions like STRTRAN(). It reads tab delimited files, not with APPEND FROM, but with FGETS(). The reason is that the fields of the import files vary and the file size can be huge. And it also writes files with FPUTS() after having done some sophisticated string manipulation. The speed is still phenominal, thousands of records/lines are processed in a second or so. But the import files can contain 100,000,000 records or even more, so it may still take a while before they're all processed.
>>>
>>>The big question now is: Will C++ or Delphi do this job significantly faster??
>>
>>Hello,
>>
>>I must say I am a proponent of C++. C++ can be significantly faster than other programming languages for many reasons. The low level function execute significantly fast, due to the nature of the compiler and the basis of the assembly code.
>>
>>You can also figure in your own assembly routines for the best optimization, which is something you can't do in FoxPro(that I know of).
>>
>>Is FoxPro an interpreted language? If so that would add a lot of overhead.
>
>Hi Brian,
>
>When VFP compiles, it generates what is called 'pseudo-object code', also referred to as 'p-code'. One might say that VFP will interpret this p-code in runtime. For my own understanding, I imagine that it's half way to real compiled code. However, the thruth might be that it's only 10 percent of real compiled code.

So its like the old Visual Basic compiler. They changed VB to compile to native code for a variety of reasons, but speed was one of them.