Memory management with SECTR

[gewl]

Hi,

I'm in the process of reconfiguring how scene loading/streaming works in my project, and am experimenting both with using SECTR and with rolling my own Addressables-based approach. SECTR seems great and very intuitive, and if possible I'd really love to avoid the finicky-seeming management of asset bundles and async op handles as much as possible.

I saw that (on Discord) Peter recently recommended commenting out the Resources.UnloadUnusedAssets() call on line 460 of SECTR_Chunk.cs to avoid the hitching from the method call. When I do that, it does get rid of the hitching, but profiling my build seems to be showing that this results in assets from unloaded SECTR chunks not being released from memory (which makes sense to me, given what I understand of how Unity handles unloading things from memory).

This isn't a huge deal to me right now, the hitching is more than fine for development. Before I start writing a whole Addressables-based thing on top of SECTR, though, I wanted to check—is this expected behavior? And (since I saw mention of some updates coming for SECTR) is there anything planned for SECTR in the future that might impact this?

Thank you!

[Peter]

On 1/7/2022 at 4:02 AM, gewl said:

is this expected behavior?

Yes, that function call Resources.UnloadUnusedAssets() forces unity to clean up assets that are not referenced anymore in the scene from memory. So if you leave that out, it is to be expected that you might see things in memory that technically are not used anymore for longer. Unity should clean those out over time by itself though.

On 1/7/2022 at 4:02 AM, gewl said:

is there anything planned for SECTR in the future that might impact this?

No, I could not think of anything planned regarding that.

[gewl]

1 hour ago, Peter said:

Yes, that function call Resources.UnloadUnusedAssets() forces unity to clean up assets that are not referenced anymore in the scene from memory. So if you leave that out, it is to be expected that you might see things in memory that technically are not used anymore for longer. Unity should clean those out over time by itself though.

No, I could not think of anything planned regarding that.

Great, thank you!

[Xeethrax]

Quote

Unity should clean those out over time by itself though.

I was attempting to create a scene loading system with Addressables, and noticed my gpu memory consumption kept going up. I started profiling and discovered that Unity was not releasing texture and mesh resources from gpu memory, even if everything was completely unloaded. What's worse was that newly loaded textures and meshes would add to the memory consumption, effectively causing a leak. Only solution was to call Resources.UnloadUnusedAssets() after each unload. In fact, that's why I decided to grab SECTR. That and the general state of Addressables atm 🙂

But this claim made me revisit my test project and loop Addressables.Load/UnloadSceneAsync() for as long as it would take to trigger such a clean up. Well I kept it running until it consumed all my gpu memory, no cleanups along the way.

Then I put Peters theory to the test, and made a similar test in our game, using a fairly populated chunk. I commentedout Resources.UnloadUnusedAssets() in SECTR_chunk.cs#460 and made a script to loop chunk.AddReference / chunk.RemoveReference. After letting it run for a while, my gpu memory was almost entirely consumed:

Same as with Addressables. I can only conclude that you _have_ to use Resources.UnloadUnuseAssets() to avoid memory leaks in such scenarios. Of course - I would love to wrong about this.

Personally I dont feel like UnloadUnuseAssets() causes that much of a hitch, as long as you keeps your chunks layered and sensible and spread out the loading/unloading as much as possible.