What is "Other Native Memory" in Memory Profiler?

I noticed when memory profiling that almost 50% of my game's memory usage falls into the "Other Native Memory" category. This is a little vague, and I could not find any explanation of it in the documentation. Does anyone know what this category includes?


We're aware of its vagueness and are exploring how we can eventually make this breakdown and its categories a bit clearer. Right now, a good part of the issue is that we don't actually know on a per-object basis, how much of the memory we have reported for objects in the snapshot data goes towards CPU vs GPU memory. Their GPU memory would add to the Graphics category, but even types of objects like Texture2D don't fully live on the GPU but have an amount of CPU memory they take up.

In the meanwhile, I'm currently implementing better explanations for these categories right in the Memory Profiler to be shown on selection. My draft for Other Native Memory is:

Other Native Memory that does not fit into the categories of Graphics, Audio or Profiler. You can find this memory present in the Tree Map and the All Objects Table below it, but that also includes All Managed Objects as well as Objects which have part or all of their memory counting towards Graphics and Audio Categories, while excluding Native Allocations that are not used by Objects. To exclude Managed memory, you can use the Objects and Allocations page and look at the All Native Objects and All Native Allocations tables. The Fragmentation page also shows the Native memory that is Reserved but not yet Used by Allocations as dark green. This category also includes the CPU side of Graphics Asset memory. Aside from that, this memory is used by Objects sch as Scene Objects (Game Objects and their components), Assets and Managers and native allocations including Native Arrays and other Native Containers.

Does that help?

1 Like

Thanks a bunch for the quick response!

This is definitely helpful, although I'm still a bit confused on one point. :)

Your draft says that "you can use the Objects and Allocations page and look at the All Native Objects and All Native Allocations tables", but doesn't that contain Graphics/Audio memory as well? Is there a way to exclude all native objects/allocations that do fall into a particular category (e.g. Graphics), so that by process of elimination, all that's left are the "Other Native Objects"?

[quote=“CDGCaleb”, post:3, topic: 869228]
but doesn’t that contain Graphics/Audio memory as well?
It does. But we are:
A) lacking data on the GPU vs CPU split in the snapshots to filter out Graphics memory and
B) filtering capabilities in the tables to exclude audio objects or allocations and profiling allocations

For point A, we are working on getting the data, for point B we are working on new UI Tooltkit tables with better filtering capabilities. The old ones are unmaintainable and IMGUI.

We might also still end up with completely different high level categories as we improve the Memory Profiler and its data capture.

The 0.5 update with that change has now been released btw.

Hi @MartinTilo

I try to understand this Other Native memory section and still confused how can I understand what it consist of so I can optimize it

my case looks like almost everything in game allocated in this section:
it is from Memory Profiler 0.7 Unity 2020.3.32

Can you say a bit more about how can I understand where this memory was used please? :)

@JesOb Have you been able to exclude that it isn't a sort of memory leak of a specific type that causes this?
Like does the value adequately decrease as expected step by step if you start removing objects from your scene?

It was Asset Bundles
When Unity load Bundle to memory it dont track memory of it and we have other native memory section for it

1 Like

[quote=“JesOb”, post:9, topic: 869228]
It was Asset Bundles
When Unity load Bundle to memory it dont track memory of it and we have other native memory section for it
I indeed noticed an increase in the “Other” category as well because of loading in Addressables. However even when unloading/releasing these assets it will still slowly creep up and starts reserving more space as well. Did you encounter the same issue? I suppose its due to fragmentation but am not sure.

We consider Addressables as unusable package so we roll out our own solution for project on top of raw bundles api.

I dont know what Addressable do currently but in our case Default compression for bundles was root cause of big memory consumption. Just changing it to LZ4HC was a fix for us :)

If it's in the Other Native Memory, or in 1.0.0 "Native Memory, it is tracked (btw you can open snapshots from unity versions before 2022.2 in an empty 2022.2 project and use the All If Memory table). All of the memory in this category is listed in the tables, All Native Allocations (pre 1.0) or All Of Memory contain them. From 2022.2 onwards GPU memory is also reported separately so that the breakdown bar and the All Of Memory table line up along the clarified classifications. We're also continuing to improve the clarify on these categories via their descriptions, that you can see by selecting the bars or table entries for eachbof these on the summary page.

If the reserved portion keeps growing, that could be because the high water mark is moved up during loading, or because of fragmentation, yes. There is currently no really easy way to analyze for fragmentation.