Profiler Window Memory vs Profiler.usedHeapSizeLong

News & General Discussion
1

Doing a deep dive into profiling memory I found aaaaaall the online posts on best practices, methods, opinions and all that fun stuff. But in doing my own experiment I am running into something that confounds me.

So I have a test app where I start with an empty scene and then load assets in using Resources.Load.

In this app I am both hooked up to the Profiler, but I also write to an on-screen text element with Profiler.usedHeapSizeLong.

So in essence I am looking at the Memory Profiler window’s “Used Total” and in code I’m looking at Profiler.usedHeapSizeLong

In Editor those don’t match up at all, but they at least increase at about the same rate when I load new assets into the level.

My problem is that on device, while the Profiler window increases when I load in new assets, the code Profiler.usedHeapSizeLong stays about the same. It’s also wildly off from where it should be.
This is on both an OSX and an Android build.

So is usedHeapSizeLong just not accurate on builds? Or am I looking at it wrong? I admit that I am reaching the limits of my knowledge on memory profiling.

For a bit of background I’m trying to understand something that I have read numerous posts on and yet can’t seem to find any definitive answers to, at least not with any data backing them up. Just people saying “well of course it’s this” followed by “no, it’s obviously that”.

That question is, if I have PrefabA that references PrefabB which has MaterialY which uses MaterialZ which references TextureZ, when I have PrefabA in my scene, is TextureZ loaded into memory?

I did another test that was basically that ^ and the profiler tells me that yes, that texture is loaded into memory. But then I’m told by someone else that “no, that’s just a reference to TextureZ”. But the profiler says that texture’s memory size is in the “Used Total”. But looking at GC.GetTotalMemory() or Profiler.usedHeapSizeLong shows different numbers…

I DON’T KNOW WHAT TO BELIEVE! Help me believe please?

2

Use Unity Technologies new Profiler for that:
https://discussions.unity.com/t/724841

It shows you if an asset is loaded into memory and how much memory it uses. There should be no need to fiddle with Profiler.usedHeapSizeLong to find out whether a specific asset eats up memory.

3

Okay from what the original profiler and profiler v2 tells me, those textures are indeed in memory.
This is what I thought at the start of all this, but it was thrown into doubt when 2 very experienced people told me it wasn’t anything to worry about because “they’re just lightweight references”. However all 64 mb of my very large test texture are clearly visible in the profiler.

1 Like
4

Always validate performance assumptions in the profiler. Even experienced devs and even our own Enterprise Support team get surprised some times and some things keep changing.

For your particular case:
Native memory (broadly speaking, your assets) will live in Native Memory Pools. As you add more assets, those buffers fill up and eventually increase in size.
Similarly, Managed (or “Scripting”, i.e.: Mono/IL2CPP) memory is a heap that will increase it’s reserved size in increments.

The Memory Map view of the Memory Profiler package can give you a better idea of how much memory is reserved for native and managed memory and how much of that space is actually used.

But yes, Assets referencing each other will hold their references in memory. Also, you might not want to use Resources.Load as, iirc, anything in your “Assets/Recources/” folder will always be loaded in memory. (don’t take my word for it, profile it :wink: )