About Monkey 2 › Forums › Monkey 2 Development › Mark – troubling memory leak
This topic contains 7 replies, has 4 voices, and was last updated by 
 DruggedBunny
 1 year, 7 months ago.
- 
		AuthorPosts
 - 
		
			
				
August 28, 2017 at 6:33 am #10051
I’m not sure about this one. I was doing another app and noticed memory leaking. This I put down to mu own shoddy programming – lol. So I did some further investigation.
Here’s the minimal App on running. I have a constant memory leak at around .1mb. I think this is something that need clarifying further by others :/
Monkey12345678910111213141516171819202122232425262728293031323334353637383940Namespace myMojoApp#Import "<std>"#Import "<mojo>"Using std..Using mojo..Const Size := New Vec2i( 950,720 )Function Main()New AppInstanceNew MyWindowApp.Run()EndClass MyWindow Extends WindowMethod New()Super.New( "window", Size.X, Size.Y, WindowFlags.Resizable )'this is a timer. it will 'tick' 60 time2 a second. calling OnUpdate_timer60 = New Timer( 60, OnUpdate60 )End methodmethod OnUpdate60()RequestRender()End methodMethod OnRender( canvas:Canvas ) Overridecanvas.DrawText( "Hello World", 10, 10 )Endprivate'the timer ticks 60 times a second and handles the screen updateField _timer60:TimerEndAugust 28, 2017 at 7:28 pm #10077Not seeing any major leak here.
Memory use hits about 35M (27M on macos) and stays there (give or take).
If you add 2 GCCollect()s to OnRender or something, you can keep memory use down to about 33M. This has greater overhead though as GCCollect is of course happening more often.
You can also use GCSetTrigger() to cause GC to happen more (or less) frequently. In this example, it’ll be taking quite a while before a GCCollect() is automatically triggered as gc trigger defaults to 4M and your app is not actually allocating that much memory, and only on at 60hz. So you will see memory use tick up gradually until a GC happens, but it should even out over time.
August 28, 2017 at 11:46 pm #10079Foe what it’s worth, here on crusty old unsupported Windows 7, it starts around 57 MB and keeps going up by 4-16k per second for a good few minutes (4-5?) — but then finally settles on 60 MB (solid 60212 K for 2-3 minutes, now 60232 K for last couple of minutes).
Think it’s working as it should! The expectation is that it would settle sooner, but I found similar results in BlitzMax, just takes time to get settled.
Still at a rock-solid 60232 K after another couple of mins!
August 29, 2017 at 3:15 am #10082Woah, not sure why Windows 7 has so much extra overhead – the app itself should be allocating exactly the same amount.
Try adding the 2 GCCollect()s to OnRender – this should give you some idea of real memory requirements, and should ‘settle’ immediately (but as mentioned above, will be slower).
You can also try messing with GCSetTrigger() – perhaps with 65536 (64K), 1024*1024 (1M) etc…
August 29, 2017 at 3:42 am #10083Apple and others warn about rendering without glClear in that it is slow and keeps old buffers alive.
Does the canvas get cleared before OnRender is called in the above example?
August 29, 2017 at 4:02 am #10086Yes, window clearing is enabled by default.
August 29, 2017 at 5:00 am #10088thanks guys. all of this is really good information to know
August 31, 2017 at 1:13 pm #10138Try adding the 2 GCCollect()s to OnRender – this should give you some idea of real memory requirements, and should ‘settle’ immediately (but as mentioned above, will be slower).
That settles quicker, though it’s still about 40 seconds until it stops increasing — and still at about 58 MB here in total. Checked, and it is release version!
I literally added two GCCollects () just before line 33 in the above code.
Just tried GCSetTrigger (65536) and (1024 * 1024) as first line of Main () and it makes no obvious difference, still same usage and timescale — always starts at about 55 MB and works its way to 58 MB over about 40 seconds.
Pretty sure Max always did a similar sort of thing — assume if it stops increasing eventually then it’s basically working!
 - 
		AuthorPosts
 
You must be logged in to reply to this topic.