Well coded low-level file i/o is faster than both string concatenation of memory variables and strtofile(cExpression, cFileName, lAdditive) for large strings. The problem with strtofile(cExpression, cFileName, lAdditive) is that it opens the file, seeks to the end, writes the string, and closes the file for each concatenation. Buffered low-level file i/o opens the file once, advances the file pointer for each string concatenation, and the buffers are flushed when the file is closed. The reason that string concatenation of memory variables is slow for large files is because of the overhead of allocating space for the result string and copying in the terms of the concatenation expression, there may also be VM page swaps and garbage collection triggered.

>From a different angle, I was doing something similar with HTTP uploads and found adding to a string in memory prohibitively slow with large uploads. The solution was to STRTOFILE in chunks and FILETOSTR back when it was complete. These commands are fantastic...
>>I have a VFP7 class with an empty string property. After instantiation, from 3 to 9 methods get called, and each concatenates 100-500 bytes in rapid succession, resulting in about a 5k stirng property when it's done. The caller consumes this string property before destroying the object.
>>
>>Would it make sense to pre-allocate memory for the object by setting the string property to Space(8192), and on the first write set the property to the first string and then concatenate after that?
>>
>>I am thinking that the object would run "faster" because the OS (or runtime) would not have to grow the stack space for the object as it runs. This is for a web app where I have potentially 60-70 objects going at any given second.
>>
>>Thanks.