>>>>>In my other thread that has 0 answers I posted the procedure I'm trying. I'm running calling the same method in a loop of 500 iterations. I ran 20+ tests yesterday and couple today - I always got the same result - the execution time of each call gradually increases.
>>>>>The clients experience exactly the same problem, so they have been restarting this dll after ~30 minutes of work.
>>>>
>>>>
>>>>(1) Does the memory size increase ?
>>>>(2) Did you use the task manager to verify that the memory size of the process increases
>>>>(3) When the execution times increase, do you infer that the memory has increased ? In case you do - not necessarily a good conclusion
>>>>
>>>>(4) It may be worthwhile to decrease the buffer space of the process - try setting sys(3050, 1, 64*1024*1024) - same for sys(3050, 2, 64*1024*1024)
>>>>Large memory buffers slow down - They were a good idea when all we had was 16MB of memory. With the GigaBytes today, a buffer that is too large slows down foxpro since it has to search in GigaBytes of memory - well not all of that memory, but the hash tables may be too large and use a lot of cpu cycles to search, even worse if foxpro were to use linear lists - which would not surprise me
>>>>
>>>>
>>>>(5) Try using sys(1104) to purge foxpro's cache just before returning from your function
>>>>
>>>>
>>>>Frankly, it does not seem like a memory leak
>>>
>>>Ok, here is what I have
>>>INVOKE GETITEM Turnaround: 0.13 Not purged memory 0 - at the beginning
>>>
>>>and after 100 iterations
>>>INVOKE GETITEM Turnaround: 0.40 Not purged memory 0
>>>
>>>-----------------------
>>>So, do you think I'm good now?
>>
>>
>>Dunno
>>
>>(1) what did you do ?
>>(2) How do these time compare to the previous ones ?
>
>For now #5 only - I think the time is about the same as it was.
>
>In other words, I don't see any improvement yet. I'll try 4) now.


Try (4) only for starters ( you may want to play with 64 and try different values) , and take it to 500 iterations so you can compare with the previous results