>>>>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
>>>
>>>Same thing - start with ~0.14 sec. and end with 1.73 sec.
>>>
>>>I'm thinking - can it help to sleep for, say, 2 sec. after 50 iterations?
>>
>>
>>So, no improvement at all - gonna sleep on it
>
>For now, no improvements at all. I removed all code except for return string from another procedure (my colleague has been testing this one) and I'll see how it performs when it does nothing - does the execution time increase or not - running this test now - hang on few minutes.
>
>From 0.02 to 0.12 - what do you think?

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.