>>>Although it's one statement, each call to strtofile() is going to open the file (and if you're using append option) seeking to the end of the file, writing the data out, then closing the file -- in a loop that's going to kill performance (especially if there is going to be an antivirus involved). If you're calling strtofile() to append to file within a loop, you're probably better off using low-level file routines -- fopen() at the beginning (then optionally fseek() to end of the file), then within loop performing a fwrite() or fputs() (fputs appends a newline for you), then fclose() after the loop. You can optionally call fflush() after fwrite()/fputs() to make sure data is being written at that moment.
>>
>>When I last tested this, here's what I found:
>>
>>For writing text files, the case is murkier. For small files, StrToFile() is about a third faster than the LLFFs. However, when the string to write is more than 327,680 (which is 320 * 1024) characters, StrToFile() has a significant slowdown, and the LLFFs are faster.
>>
>>There's more on the topic, including an explanation from Christof about why that is, in this paper: http://www.tomorrowssolutionsllc.com/Conference%20Sessions/We%20Used%20to%20Do%20it%20That%20Way%20But.pdf
>>
>>Tamar
>
>Hrm... I would've thought that FOPEN() before the processing loop, then FWRITE()/FPUTS() each record in the processing loop (i.e. leaving the file open within the loop), then FCLOSE() after the loop would be faster than using strtofile() for each record within the processing loop. If there is an antivirus involved, using LLFF would avoid triggering a scan with each loop iteration, whereas the implicit open/close with strtofile() would likely trigger a file scan each record.

That's why it's a good idea to test this stuff. What we think logically may not be the case.

Tamar