Actually VFP 6.0 string processing can be 100's of times faster on
large strings and on typical strings under 100k will still be 10 times
faster. The bigger the string the bigger the payoff.

John also posted this message on my message board and we had an interesting
discussion about the results:

http://www.west-wind.com/wwThreads/Default.asp?MsgId=S1A1C95GB

Class property performance can be sped up by not concatenating directly, but rather by using a method:

DEFINE CLASS CString AS Custom
cStr =""
FUNCTION AddString
  LPARA lcAddme
  THIS.cStr = THIS.cStr + lcAddMe
ENDFUNC
ENDDEFINE

This still runs 2-3 times slower than a local but is much improved.

Using a LOCAL for string generation would be nice, but is unllikely to be an option in most large string generation scenarios especially those using generic code. The next fastest way to do this is to use a class that sends output to file then captures the file output back to a string.

Depending on string size (over 25k) this is faster than even local string concats. The larger the string gets the better file performs compares as strings have to keep a buffer in memory, where files do not. Since files buffer internally by the OS it's blazing fast.


Check out the above thread. There are some other interesting comments there.
Click on the folder to see the entire thread.

+++ Rick ---









>Hi John,
>
>I found your tests interesting. I do, however, have a few comments.
>
>VFP 6.0 when working with local variables is signicantly (more than 100%) faster than VFP 5.0. I ran a series of tests and where 6.0 concatenated string in approximately 0.014 seconds 5.0 running the same code took nearly 2.4 seconds.
>
>I found, as you did, that concatenating an array element string was much slower, taking over 28 seconds in both VFP 5.0 and 6.0. In other words, VFP 6.0's handling in this case is no better than 5.0's.
>
>As far as objects go, I was surprised that bracketing the FOR...ENDFOR with WITH o...ENDWIDTH and using .Str = .Str +...resulted in only a marginal increase in performance.
>
>I'd suggest that you assign a the terminating value of the SECONDS() function to a variable in your tests. Passing it as a parameter to your function you're adding time (albeit rather miniscule) that is not connected with what you're trying to measure.
>
>Along the same lines, the test where you pass the string by reference really doesn't apply either. What you're measuring there is both the mechanics connected with parameter passing and string manipulation. In general, passing strings by reference is always going to be more efficient than passing them by value, with the exception of 1-3 byte strings. You'll find that when passing strings by value, the length of time connected with passing the parameter is directly connected with the length of the string. When passing by reference, this doesn't come into play.