>>Although we see it calls the growing time write_log function first, so that may be the main reason. I can comment out this function and re-test, but I think I identified the main culprit for slowness is write_log function.
>
>If you are using strtofile( with append - that is very slow
>Just ran a test - 40000 times
>strtofile( , append) = 12 secs
>fwrite()/fputs() = 0.016 secs
>
>

With fwrite - should not you first go to the end of the file? Are you saying it's better?
Can you post the test?

The changes I've made so far already done it - although I suspect I can do better. Yes, write_log uses strtofile to append.

I found the following:

In each call it first created a string it was supposed to write, added this string to property, and only then check if the verbosity level greater than needed - if so, it bailed out. I moved that code right at the top.

Few local variables were not declared as local - I added them to local declaration.

For CRLF and TAB the variables were used - I switched to defined constants.

So, these were the only changes I've done and yet the results are much better now and the time does not increase. I think the main thing is I moved the bail out case to the very top and I've been testing with the low verbosity level.

This is the current code

 strtofile(m.tcMessage + CRLF, .cProgramDataPath + iif(m.tlLongCall, .cLongCallLogFile, .cLogFile), .t.)
         if (not m.tlLongCall) and m.tcMessageType = 'E'
            * Now always make an entry into the LongCall Log when messagetype = "E"
            strtofile(m.tcMessage + CRLF, .cProgramDataPath + .cLongCallLogFile, .t.)
            if .nVerbosityLevel < 5
               strtofile(CRLF + 'Here is a log at full verbosity that led up to this error...' + CRLF + CRLF, .cProgramDataPath + .cLogFile, .t.)
               strtofile(.cInvokeFullLog + CRLF, .cProgramDataPath + .cLogFile, .t.)
               strtofile(replicate('-', 80) + CRLF + CRLF, .cProgramDataPath + .cLogFile, .t.)
            endif
         endif

What do you think we want to switch to?


>Don't forget that for every append, it has to open the file, seek to the end and close the file
>
>>I look up this procedure and it stores every message in the property, so this property is going to grow more and more and therefore the execution time is going to slow down.
>
>Adding something to a string property ( aka this.something = m.this.something + '12233') really slows down when the string gets longer.
>This originally crossed my mind - but I dropped it since it did not fit in a memory leak scenario
>
>Also, if you log, why keep the log in memory ?
>
>For large string properties, where you just append data - I prefer to use 'ADODB.Stream' http://msdn.microsoft.com/en-us/library/ms675032(v=VS.85).aspx
>I have suggested this for ( http://www.vfpwinsock.com/vfpwinsock.asp ) vfpwinsock - a class that sends an email. It builds up the message like this: this.data = this.data + ...
>When the message gets big - ie with large attachments - it really is getting slow
>
>
>
>Logging is an overhead - so the time of logging must be as small as possible
>
>
>
>Exit memory leak ...
>
>
>
>For a quick test: put return as the first statement in the write_log() function