>As an experiment you could try using combinations of DOEVENTS and .AutoYield.
>
>If all else fails you might try SET COVERAGE (don't know if that's available in a .DLL), see if the results yield any clues.
>
>In general I agree with Gregory and Thomas, it doesn't look like a memory leak. With a leak, normal behaviour is that everything works fine until the leak causes a resource to become critically low, at which time the function ceases working at all, or execution time goes way up (sometimes orders of magnitude). You don't usually see a linear increase in execution times.
>
>Usually, a linear increase in execution times means a linear increase in the actual workload being performed e.g.
>

>SomeString = REPLICATE( "X", 100000 )
>
>FOR i = 1 TO 100 STEP 1
>  SomeString = MakeBigger( SomeString )
>
>ENDFOR
>
>FUNCTION MakeBigger
>
>LPARAMETERS tcString
>
>RETURN tcString + REPLICATE( "X", 100000 )
>

>To see if something like this is happening, you can examine your inputs at various points of your iterative testing.
>
>Another thing worth checking is scope of variables you're using. You can get any number of weird effects by failing to declare your LOCALs, especially with looped/iterative code and most prominently with recursion.

I don't think DoEvents and AutoYield are relevant for DLL. Good point about what is memory leak. However, I don't think the other problem applies, as I believe in all procedures I use local parameters and variables. I did find one main procedure using parameters instead of lparameters, so I've changed that and I think I set local parameters. However, I'll take a closer look - there are only handful of procedures we're testing.