Learning to use the Memory Profiler package

happy to hear that!

Actually, the managed heap usage grew, the heap itself (reserved size) is still the same size so that wouldn't affect the Total amount of Memory occupied by Unity... Sadly that makes it even less clear where that increase came from

Also, technically only something like 21 MB difference would be needed depending on the exact numbers and rounding. Also, I just checked and there is a minor of precision loss going on in EditorUtility.FormatBytes(), which is used to display all Byte sizes in the Profiling tools. Basically it does int divisions by 1024 until the value is in range of the right order of magnitude and only then does a division as double and passes it on to formatting with rounding, using IEEE 754 rounding rules.

That all said, this does look rather off. If you could file a bug report with these two snapshots attached and ping me the issue number, I can check out if there is some further imprecision going on that we can fix or how to show that difference better.

Yeah, you're not the first one to be confused by those size columns. We really do need to clarify them. We had already renamed them a bit but will simplify the size display and clarify the columns as we overhaul the tables in general.

But basically: you are looking at the "All Objects Table", so that's a mixture of Managed Objects (all objects on the Scripting Heap) and Native Unity Objects (All C++ Objects inheriting from UnityEngine.Object, or rather, it's C++ equivalent).
All Unity Objects (i.e. originating from types inheriting from UnityEngine.Object) can have a Managed Shell Object, i.e. a Managed Object that allows C# code to interact with them.

So Unity Objects can consist of:

• 0 or 1 Native Object
• 0 or 1 Managed Shell Object

Thus, they can have a Managed Size and a Native Size. Also, all pure C# Type objects (not inheriting from UnityEngine.Object) will obviously also only have a Managed Size.

The Field Target size only applies to fields on Managed Objects, i.e. if you fold out a Managed Objects, you can see for each field the Managed Size that is inherent to this object. If it is a reference field to an Object, the Managed Size of that field is the size of the pointer, and the Field Target Size the size of the referenced Object. Since that Other Object will appear elsewhere in the table (at least in an unfiltered All Objects or All Managed Objects) table, this avoids double counting the memory. We want to simplify this though, especially for cases where the referenced object has nothing else referencing it, so it can technically be counted as "owned" by this object.

Unfortunately, the current All Object Table logic only partially stitches the Managed Shell Object and the Native Objects together. The result is that a Unity Object that has both will show the Native Size on the Managed Shell AND on the Native Object, as both will appear in the table.

This means that the Native Size summary show for Group headers like your Diff table groups of "Same" "New" "Deleted" may be inflated by double counting the native size for any Object that has a Managed Shell.

That logic error needs fixing but that goes a bit deeper into the entire Table logic and is therefore scheduled to happen with the general table overhaul. So this should get simpler in the future.

The double counting may only account for, at max, a doubling, so I guess something else is funky with that math... I can't tell what from this high level view. If I had the snapshots, e.g. via that bug report, I could try digging a bit deeper ...

Is this happening while comparing snapshots or also while looking at just one? I think we need to take a long hard look at the tables and grouping logic but specifically with Diffing, I think that a group containing rows with mixed Diff column values might be funky on the group header summary with the sizes?

 

Thanks for the report, I've taken a look and figured out where those missing 27MB went. The rounding was all accurate enough but the Executable And Dlls part was bigger than the otherwise untracked memory.

Attributing all of that executable memory as considered-in-use-by-the-os (the Total value) is wrong and something we're looking into fixing. It's quite the messy situation across platforms and not always possible to get good numbers, and some platforms don't include the Executable And DLL size in the total in use memory stat at all. I was already working on a UI fix/temporary workaround that would at least trim the usage down to what is maximally possible, but that needs some Highlighting and explanation in the UI as in e.g. your case it could then look like the Executable And DLL size grew while it was really either that more of it was considered dirty, or that the Untracked amount grew.

So for your two snapshots, the usage grew by 27 MB in either the amount of executable memory that was considered dirty, or in Untracked (or a mix of both). But it's impossible to tell for the memory Profiler. You'd need to check this out with xCode Instruments

 

I've made the bug public and found another issue somewhat related to the mismatch in New and Deleted, possibly causing the discrepancy there, or at least to a degree. Somehow the Snapshot Crawler in the package fails to properly link up the some of the Managed Shell Objects with the Native Objects in the second snapshot, so they don't have a Name or Native Size.

Thanks again for bringing this up and reporting these and please ignore the part of my answer email where I forgot to change "Custumer QA" to "Developer in the Profiler Team"

 

Aye, we need to surface that info better. It currently lives in the Known Limitations section of the package's documentation index landing page. I'll also look at getting that info directly into the tool.

 

Yeah it applies to Others too, though since that bit is included in the data, it's a little less nebulous, though with the current snapshot data hard to specifically attribute to single objects and allocations. It's the Native Heap excluding Audio, Profiler and GPU side graphics parts. I.e. it includes the native sizes of Scene Objects, Assets (CPU side only for stuff like Textures), Subsystems etc. So generally looking at Native Objects should show that, but the other bug I found via your snapshots may make pinpointing a bit more tricky.

The System Allocator warning currently doesn't work correctly on all platforms as there is an issue with the reporting of the memory regions. A fix for that is in review. Unless you went out of your way to enable the System Allocator, you can ignore that one for now.

 

Taking a snapshot on the device doesn't trigger the GC. If you want to be sure, you'd need to turn off incremental GC, call GC.Collect and GC.WaitForPendingFinalizers before triggering the capture via API.

You won't see any managed memory in the snapshot that is about to be collected by the GC, because that memory has no rooted reference chains pointing at it that the snapshot crawler could follow to find it. So the only difference you'd see between before and after GC.Collect is that sometimes you might see less empty heap space.

What variations are you seeing though?

 

Ah yes and btw, 0.4.3-Preview.1 contains the fixes for the UI Total numbers not matching up to the totals of the bar's elements and for the managed and native objects not getting stitched together properly in that second snapshot you submitted. Thanks again for the report

 

As per the issue tracker item for that, it's fixed in 2022.2.0a1, the fix is not getting backported,so it wont get fixed on 2021.3. As before, just ignore the warning on those versions.