Mark – troubling memory leak

Home Forums Monkey 2 Development Mark – troubling memory leak

This topic contains 7 replies, has 4 voices, and was last updated by  DruggedBunny 2 weeks, 4 days ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #10051

    AdamStrange
    Participant

    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 :/

    #10077

    Mark Sibly
    Keymaster

    Not 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.

    #10079

    DruggedBunny
    Participant

    Foe 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!

    #10082

    Mark Sibly
    Keymaster

    Woah, 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…

    #10083

    Simon Armstrong
    Participant

    Apple 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?

    #10086

    Mark Sibly
    Keymaster

    Yes, window clearing is enabled by default.

    #10088

    AdamStrange
    Participant

    thanks guys. all of this is really good information to know

    #10138

    DruggedBunny
    Participant

    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).

    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!

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.