Why are there inconsistencies in the memory profiler as well as memory profiler and task manager?

I’m noticing that all around, there’s inconsistencies on how much memory is being used in the memory profiler. I’m on version 5.0, the latest version.

I’ll notice that in the summary (the first dropdown at the top), it’ll say that 12GB of memory is being used/tracked with 2GB of memory untracked (this is alarming in itself but less-so when I see other results).

I then go to the tree-grid below the summary dropdown and all of it adds up to less than 7GB of memory?

I then go to the task manager and notice that my game is using 8GB of memory.

Why are there such discrepancies in the memory profiler?

The Tree Maps and default Table underneath it is filtered to show all memory used by Objects, native or managed. There are also non-object associated native allocations and preallocated pools and buffers. The Fragmentation Page, the All Native Allocations Table and the All Memory Regions Tables give a more complete picture of memory usage, albeit less concrete in terms of items one usually encounters within the Editor.

To give you a better explanation of what might be going on with your discrepancy between the total used in the tool vs Task manager it’d be good to know if your, as it sounds, using windows, which Unity version you are using and what that memory usage overview looks like for that snapshot.

Generally speaking though, is this something we are working on closing the gap on, including the Untracked part. What could constitute the Untracked amount is displayed in the Memory Profiler windo when you select that bar or the row for it.

to add to what Martin said:

  • TreeMap displays only a portion of memory attributed to UnityEngine.Objects and managed C# objected

  • We’ll updated it to display all memory we know about it in the coming releases.

  • Task Manager and Memory profiler relation is not 100% clear

  • There are 2 important concepts to know about - Working Set/RSS and Committed Memory

  • Working Set is the portion of memory app has in physical memory - https://docs.microsoft.com/en-us/windows/win32/memory/working-set

  • Committed Memory is the memory allocated by a process and that maybe in physical memory or swap file

  • You need to know both actually

  • Working Set defines the app “memory pressure” on the system and may be a metric of how likely the game is going to be killed by OS

  • Committed memory allows you to see all allocations and understand whether or not Unity tracks all memory :slight_smile:

  • Task Manager displays Working Set and Memory profiler (on Windows) starts breakdown from Committed Memory

  • Tools like Process Explorer or VMMap can show you the real picture (on Windows)

  • Our goal atm is to surface this information to the tool so that we are consistent with OS tooling

  • It is quite challenging if we take into account all platforms :wink:

1 Like

First of all, I do thank you for putting thorough descriptions in the memory window, that has helped out already. For instance, I didn’t know that having read/write enabled will double it’s memory ingame.

Second of all, thanks to alex’s reply, I think at this point, I’m just going to have to wait it out since it sounds like unity’s memory manager keeps track of all the objects currently referenced or having references in the scene, but anything that isn’t related to an object will be in the ‘unknown’ category.

But to give more insight into my specific problem, here’s a few screenshots from the memory profiler on my discrepancies.

Task Manager-4.2GB of memory: 7876765--1001536--upload_2022-2-7_15-8-20.png

Memory Profiler-7GB of memory (with 5.71 being tracked):
7876765--1001539--upload_2022-2-7_15-8-59.png

Grid-5.2GB of memory is the sum of all these grids:
7876765--1001548--upload_2022-2-7_15-9-27.png

So you can kind of see where I’m getting confused.

Oh you also wanted the specs so this is Unity 2020.3.25f1 on a Windows 10 GTX 1050 laptop

No. Everything the snapshot has information on is in the Tracked category. Wether that’s Object associated or floating allocations or preallocated buffers. But the tree map only shows objects. You’ll have to look that the Objects and Allocations page and choose the All Native Allocations Table or the Fragmention page. There is information for all of the 5.44GB of Tracked memory in the snapshot.

Unknown contains native plugin memory, IL2CPP Virtual Machine memory, etc as listed in the UI when you select it.

The other bar would be interesting to see in this context, the one with the Graphics & Graphics Driver category. E.g. I’m not certain how much that category is measured in the Task Manager, as that might not list dedicated VRAM usage? If you switch from Task Manager to Resource Monitor, that may become clearer too.

Also Executable and DLL may not fully count as working set. A can part of it be shared with other apps (Because that’s what a dynamically linked library allows for) and it is likely not modified after loading from disk.

I use Process Explorer.
9107278--1262704--process.png
Private Bytes is 407660KB, 407660kb = 398MB
9107278--1262710--profiler.png
Total Committed Memery 400MB, the two value means the same thing?

Yes, it’s the same.

As for the difference, memory usage can fluctuate, and results might differ depending on the moment a sample is taken. We take samples around the frame end. Process Explorer probably takes them with a specific fixed time interval. Something inside Unity might allocate/release memory in between these intervals.