SRL Archive - OSR Help

So i lifted this code from Dgby714's post in the Extensions thread on Appa

Works great, I'm able to color search in the appa window and everything, but the problem is after thousands of function calls everything starts to run very slowly. I only deal with bitmaps in this function call, and there doesn't seem to be any problem with unfreed bitmaps (Target isn't freed, but it is being constantly updated and I free it upon termination). So what's up with things slowing down? Do these appa functions have a memory leak or is something wrong with the code here?

btw, in the try block after appa_Copy, I inserted this line Bitmap.Canvas.Pixels[0, 0] := 0; as suggested by nielsie95 to activate the canvas.

procedure appa_UpdateBitmap();
var
w1, h1, w2, h2: Integer;
Bitmap: TBitmap;
begin
if (not (appa_Showing())) then
Exit;

appa_GetSize(w1, h1);

if (Target = 0) then
Target := CreateBitmap(w1, h1);

GetBitmapSize(Target, w2, h2);

if ((w1 <> w2) or (h1 <> h2)) then
SetBitmapSize(Target, w1, h1);

Bitmap := GetMufasaBitmap(Target).ToTBitmap();
try
appa_CopyContentToBitmapDC(Bitmap.Canvas.Handle);
GetMufasaBitmap(Target).LoadFromTBitmap(Bitmap);
finally
Bitmap.Free;
end;

SetTargetBitmap(Target);
end;

Just check if function is leaking:

var Target : integer;
begin
  appa_ShowForm; 
  for i := 0 to 1000 do
  begin
  appa_UpdateBitmap;
  wait(10);
  end;
end.  

and observe you RAM…


I didn't notice memory stack running this function.

And no,from my experience APPA doesn't have any leak. It has few bugs actually ,but no leaks.


Are you sure that slowing down is caused by memory leak? Have you observed increased memory usage?

That's what's so confusing for me. I did this very test a few days ago and did not really observe increased memory usage. But the iterations were definitely slowing down :( (the first 1000 iterations was 4x faster than the last 1000 iterations in 10k iterations). What else could be slowing down run-time in such a test?

If I did multiple runs, each run would be slower than the last until I restarted SIMBA

Edit:

Just realized that in my test, I actually load a bunch of instances of my custom type in the beginning (part of a larger script I was too lazy to change much to run this test). The type consists of a TIntegerArray and a TPointArray. I have a function which I use to load the type, so it returns an instance of the type (stores to Result). From what I've read, it seems that this is actually a leak, correct?


function a(integer array, tpoint array): customType
var
cType: customType
begin
cType.intarray = integer array
cType.pointarray = tpoint array

Result := cType
end


So apparently this creates an instance of customType that will not be freed upon exiting the script? Also, does my type "own" the arrays or just the pointers to the arrays? Is this function also creating unfreed int and tpointarrays?

I'm much more used to memory management in C. I guess I'm also wondering more generally when we're dealing with pointers and the actual objects themselves. Can I have a function return a TPoint through Result :=, or does this result in an unfreed TPoint? What about Enums?

Test it first (seperately)…

program new;
type MyT =  record
 I : TIntegerArray;
 T : TPointArray;
end;

  function MyTest(TIA : Tintegerarray ; TPa : TPointArray ) : MyT;
  begin
    Result.I := TIA;
    Result.T := TPa;
  end;

  var a : integer;
  var myt : MyT;
  var TIA : Tintegerarray;
  var TPa : TPointArray;

begin
  setLength(TIA,10000);
  setLength(TPA,10000);

  for a := 0 to 10000 do
    myt := Mytest(TIA,TPA);
end.    

No leak for me.

Yes , actually Simba is leaking like … uhm old boat , there is well-known(? :p ) memory leak http://villavu.com/forum/showthread.php?t=82077 ,but it happens only for inbuild Simba functions (which returns arrays and propably custom types) and for functions from Simba's plugins. It's old PascaScript issue I think.

But your custom made functions should not leak.

So I don't know your code ,but suspect ,you may have leaks from TPA functions.

Thanks a lot for the help man :)

Guess I'll just have to test those functions to see if they leak lol. Wish there was a tool to check allocated memory before and after. I have one for C; maybe someone much smarter than I am can bring that to fruition :P


I'm curious as to why everyone is only talking about unfreed TPAs. TPoints are types too… shouldn't functions that return TPoints also fail to free said TPoints? Or is it that TPAs are allocated on the heap and therefore require different memory handling methods than something like TPoints, which always take the same amount of memory?

Figured out the source of the memory leak. It is Appa_navigate(url) and possible Appa_SetTargetName('')

Someone else had pointed this out in Nielsie95's thread, although Nielsie says it's internet explorer caching things. However, when I stop the program, SIMBA is still hogging my memory. What does this mean? Any fixes?

Btw, to truly observe the memory hog, loop navigating to different pages (not just the same page over and over).

I haven't noticed it before, as none of my scripts loops throught many different pages frequently, but I see it now after some testing.

I don't think there is any leak in Appa_navigate(url) ,it's just opens url in browser. If you navigate to different sites manually using APPA's adress bar, you would propably get the same effect.

Yea,when you stop APPA script from running manually it won't free any memory. But you can free most of memory this way:

  appa_Navigate('about:blank');
  wait(1000);
  appa_CloseForm; 
 

However ,as you said ,there are still some junks in simba's memory even when appa form is closed. I believe the only way to fix it is restarting Simba.