>>>>>>>With all the small changes I made so far (restoring back calls to MySQLExec) I get 0.21 as first call and 1.77 as last call for 500 iterations.
>>>>>>
>>>>>>
>>>>>>The time of execution bears no relation to the memory leak imo
>>>>>
>>>>>IMHO, if execution time gradually increases for the same call with exactly same parameters - does not it indicate a memory leak?
>>>>
>>>>
>>>>Why should it ?
>>>
>>>Why not? How do you explain it otherwise? And also, what is the simple test to see if the memory is leaking or not?
>>
>>
>>>Why not? How do you explain it otherwise?
>>Lots of reasons
>>- the system may be busy with other (non-fox) programs/services/ etc
>>- it may garbage collect variables
>>- decrease it's memory allocation
>>
>>
>>The tests have to be run at least a couple of times to reduce influence from the above
>>
>>
>>> And also, what is the simple test to see if the memory is leaking or not?
>>
>>Call the function continously - look at the memory it takes in the task manager
>
>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