While trying to reduce memory usage, I invariably run into the situation pictured below: the vast majority of memory is “Other Native Memory” and looking at the native allocations gives little to no actionable information:
How does one get more detail about the root causes of this native memory so that we can reduce it? Are there build settings we can use that will expose more?
Actionability of the native allocations is a huge topic that needs more exploration and work from our side. While some allocations may be actioned from c# code or asset configuration, unfortunately most of those can be acted only when you have a source code.
In the screenshot you’ve provided:
UnsafeUtility is what was allocated in C# UnsafeUtility.Malloc calls - can be acted potentially, the information you might need for that is a callstack though
BaseObjectManager is a native hashtable that tracks all live UnityEngine Object instances - why is it 96MB is a good question.
No Root is an allocation which is not associated with any system and is a memory tracking bug we would like to fix.
“Objects” allocations are internal Unity Objects which were created to support some system - may be a bug or a system overhead (e.g. default texture/mesh)
There are no build settings, sorry. The source of native allocations atm may only be tracked if you have a source code license and can build Editor or Player from a source code.
I do have a source code license. Who would I contact in order to find out more about how to use that to track these? Do I just build the editor and player modules with jam, keep the source code around, build from that Unity editor, and then run on the same box?