Hi David,

>>As the "lcEscape = replicate( "%", lnLength / 2 * 3 )" is included as well as the calling overhead of the parameters I do believe the factor between both measurements will be different if you are repeating the call a couply of thousand times for smaller strings. If the source string length is more in the range of 50 - 200, Substr() should be faster.
>
>VFP can allocate memory pretty darned fast. My box an average of 0.115 seconds for 10,000 iterations rather than one large sring. This ends up taking right at twice as long as doing one string 10,000 times longer.

My post was probably not long enough on all points to be clear<g>. The Substr() is faster than sys(2600) on smaller strings, and vfp as an interpreted environment sometimes is "good enogh" for some string length ranges with simple optimizations inside the vfp code. OTOH vfp can show abysmal perf when working on areas not "nice" for it. The most fitting benchmark uses the data needed for the specific problem.

If it is clear that a bottleneck remains in string-manioulation, even "straight-ported" C (using similar array structures and not pointer-movement optimized solutions) will give you considerable headroom - I am just now testing a non-optimized C based implementation of the LevenShtein-Algorithm which gives an approx. speed factor of 25 over the vfp based solution. Implementing first in slightly optimized vfp helps *me* decide if such a C module is *really* necessary AND gives me an easy way to test my C function.

But it also seems I was quite off center in my picture of the OP's C-knowledge, which lead me to argue heaviliy against C in shop where presumably no such knowlegde existed<bg>.

regards

thomas