[snip]
>An example that might do the different strengths of VFP and C++ more justice is a simple EDI scanner class that I wrote a couple of years ago for use at $ORKPLACE. This did about 1K lines per second but performance was becoming a problem, with input files in the multi-megabyte range and whatnot. So I looked carefully at the problematic portion, which was the code that splits a segment (input line) into an array of data elements. By applying traditional Fox code optimization techniques (slimming *g*) I was able to speed the code up to about 7K lines/s; and using ALINES() to do the splitting for all lines that do not contain a release indicator pushed performance to 20K lines/s. But I just recompiled a fairly straightforward scanner that I wrote in C++ when I wrote the original Fox code five years ago, and I had trouble locating an input file that would cause it to take at least 0.1 seconds to scan and dissect. Result: over 4 million lines per second, even though the C++ code does quite
>a bit more than the Fox code (char set translation via lookup table while scanning, etc. pp.).
>
>But I am still using the Fox code because at 20K lines/s the raw EDI parsing isn't the limiting factor anymore; the limiting factor is now processing the data - including database work - and for that Fox is still the best. *g*

A similar application is currently done by me. Some critical person 'suggested' it could be done faster with C++, although the app does a tremendous job compared to .. nothing. I was not sure about it, that's why I started a thread some weeks ago here on the UT.

Since then, several thoughts have come to my mind, partially based on the replies and yours too.

1) Seeing several thousands of textlines processed per second in a thermometer can be a magical experience, even if the processed file has millions of records. For some vague reason I think it can be far more magical than seeing the whole file processed in a split second. A split-second processing can let the user think that it's all 'no big deal'.

2) It is only version 1 of the app. Now we have the potential of creating updates that give 'dramatic' performance improvements. And it are essentially only sales of version 1 that should be the impetus for further development.

3) Traditionally, version 1 is the version that proves that technically the job can be done. (Version 2 will be the 'service pack' and version 3 will have a performance boost on board besides new functionality.)

4) As in your app, only a part of my app is eligible for C++. However, coding that part in C++ would consume much more time than it has now consumed and I'd also have the problem of optimally integrating it in vfp. Not only speed would boost, the costs for the customer would boost also.