I found it somewhat surprising that a straightforward implementation via std library algorithm templates was able to keep up with VFP's builtin functions. I guess this reflects more on the chosen test data than on the issue VFP vs. C++, since the implementers of AT() and OCCURS() necessarily had to make some assumptions about what constitutes 'normal' usage and tailor their implementations accordingly.
If algorithms are chosen specifically to suit a particular class of problems then you can be dramatically faster; in the case of substring counting/searching likely candidates for largish input strings are Boyer-Moore, KMP and Shift-And-Search, just to name a few. But these algorithms incur a small setup penalty over more straightforward approaches and so they are a little slower if only small strings need to be searched in. Fastest would be a function that looks at the inputs and dispatches to an appropriate specialist for the given inputs, but of course this requires much more effort to implement than a straightforward solution and so it is not worth it unless analysis shows a need.
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*
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only