Unity: 2019.4.37f1
Addressables: 1.19.19
Memory Profiler: 0.6.0
Hello,
After making changes to our game so that assets/scenes are now loaded from Addressables we are seeing a large memory spike when assets are being loaded from bundles. Memory increases, levels out and then drops off again. The reduction in memory usage corresponds to calls to Shader.ParseMainThread.
In the profiler most of the memory appears to be taken up by “Objects” which appear to be “Single Large Allocation Memory Block” according to the profiler.
Has anyone else come across this issue, and knows what is causing these allocations? This wasn’t an issue when everything was in the build and it is now causing crashes due to running out of memory.
Object count is hard to know for sure, as everything is an Object (GameObject MonoScript etc).
A lot of the small ones are likely MonoScripts and large ones could be Shaders or Textures etc. 74k Objects may sound like a lot, but it doesn’t seem too outrageous to me.
In terms of the memory overall increases and dropping off when you load. My go to guess would be that this could be a large bundle, that has LZMA compression or CRC enabled?
1 Like
It looks like we have a single scriptable object that has a complex dependency chain and ends up loading assets from around 114 different bundles (all our bundles are using LZMA compression). When I moved that scriptable object and all dependencies into a single large bundle (135MB) I didn’t see the same kind of spike in memory.
I understand there is an overhead cost when loading bundles and I believe this is represented in various ways in the profiler through “AssetBundle”, “SerializedFile” and “PersistentManager.Remapper” sections. I wasn’t expecting to see “Objects” section in the profile be so high and then drop off when loading assets. I am unsure what “Objects” represent, is Unity reserving memory it thinks it needs for loading assets from all the bundles then freeing it?
Also at this point in the memory capture during the memory spike there isn’t a lot of actual assets in memory (Textures, Shaders, etc) that would account for the memory usage. Just these “Objects” that show up as native memory allocations when viewed from the memory profiler.
Things showing up under Other>Objects in the Detailed Memory Capture of the Memory Profiler Module in the Profiler window, or as Object Allocations without a proper Unity Object root in the Object tables in the Memory Profiler package are always a bug in the Unity Player backend (though some small, non-growing amount on older versions is unlikely to get fixed), because it means some allocations are using the wrong code path and are not properly rooted.
Some of these has been related to Addressables and fixed in a combination of Unity and Addressables package updates and backported to 2019.4.35 and should be gone with the latest versions of addressables . If you’re still experiencing that on these versions, pleas file a bug report via Help > Report a Bug in your Editor and submit your project or a test case so this can be analysed and addressed 
(Also this is mostly a bug for the debuggability/analysis of the memory but can also, but not necessarily, be indicative of a memory leak in our native code)
(Updated as I found the old threads and bug reports again)
1 Like
Thanks, that explains why I am seeing “Objects” in the profiler If these “Objects” are potentially objects/assets that aren’t being properly tracked/native memory leaks then I am still confused as to why we are seeing a spike in memory usage during the loading of assets from Addressables. We aren’t unloading any assets at this point in the game so I am not sure why memory would then drop down once the loading is complete.
It might be de/serialization objects or loading buffers that aren’t retained past initial load times.
Or just bundle manifests or TypeTrees? There is a bit of overhead associated with every AssetBundle and reading that many simultaneously might spike out due to reading all of them and possibly doing so in parallel with sync fences. Iirc some faulty sync code was causing the leak before so that’d track.
Also, the object allocations might be backing memory that might not yet be assigned to an object root while reading it in but get assigned to it later in the process when it is Awoken on the main thread (not sure if that would be an assignment or a re-alloc though).
The newer All Of Memory tables in 0.7.0-preview.2, opened with an Editor on 2022.2 (the snapshot can be imported or captured from an older Player/Editor’s Unity version) would show such Object → [1…n] Native Allocations connection in a later snapshot but there’s currently no way yet to diff or filter by allocation in those tables. I’ll keep that in mind though.
1 Like
