Official Memory Profiler 1.1.0-exp.1 Released

Hello y'all

We have released version 1.1.0-exp.1 of the Memory Profiler package. This version brings new functionality under the themes of improving Resident vs Allocated Memory analysis and improving Managed Memory analysis. It also contains a good set of fixes for bugs and usability issues you've raised since the 1.0.0 release. See below for details of what’s new.

What we’ll cover

• Resident Memory Information
• Managed Object Search Improvements
• Improved Comparison Mode
• Render Texture Details

What’s New
Resident Memory Information
Problem
If you only look at Allocated Memory, you might be misled by which allocation consumes your physical memory and optimize something that isn’t a problem. Consequently, you waste time and do not see any difference in your application performance and stability.

What is Resident Memory?
Resident Memory is the amount of physical memory used. This amount is usually lower than the Allocated (committed) amount of your application, as some allocated space may yet be untouched ("empty"), or hasn’t been accessed for some time and moved by OS to a secondary storage, for example page swap file or compressed memory. The amount of Resident Memory is therefore the primary number used by the OS when it determines whether or not to kill your app. I.e. if the Resident Memory usage of your app exceeds the physically available memory, or the amount of memory determined by the OS to be safe to be used by just one application, it will deny further allocations (OutOfMemory exception) or directly terminate your app.

In this version of the Memory Profiler, our goal is to guide you through the differences in Resident Memory and Allocated Memory so that you can easily see where the potential problem areas are.

Changes We’ve Made in 1.1.0-exp.1
We have added the ability to see how much memory each native object, C# allocation and other reported entries contribute to the Resident Memory amount. This is available for all snapshots taken from Unity versions 2023.1+ and on Windows, Linux, Android, MacOS and iOS.

The Summary View's bars show the Resident Memory bars on hover and all tables now have different view modes, which allows you to switch between Allocated/Resident/Allocated and Resident views via a drop-down next to the search field above the table. We’ve also updated the description shown when selecting the Total Resident On Device bar or legend row on the Summary page with more descriptive and hopefully more helpful explanations of Allocated and Resident memory.

We've also published a blog post with more info on this topic.



Managed Object Search Improvements
Problem
We've heard your feedback that it was not possible to find an object of a specific type in 1.0. And that managed objects had a generic “<No Name>” name.

How We Solved It
In 1.1.0-exp.1 we expanded the search functionality to include any value used in the Description column of a table. You can now search by type, any other group names (like "Graphics" in the All Of Memory table), and by the managed address value or instance ID. Managed addresses are now displayed in the All Of Memory table for managed allocations.

We added the post-fix "(Leaked Managed Shell)" to managed UnityEngine.Objects with a Destroy()ed native object, so you can now easily search for all leaked shells (more info on those has been added to the documentation) in the All Of Memory view.

Scripting Types You’re Familiar With: Managed Types Inheriting From MonoBehaviour & ScriptableObject
In the Unity Objects table, all of your scripting types that inherit from MonoBehaviour or ScriptableObject are now subdivided by their managed types. This not only allows you to search and filter by those type names and namespaces, but also helps to analyze which of these types have the biggest impact on your native memory usage; which is mostly a factor of their total count and their serialized data. This also makes the Potential Duplicates analysis more precise.


(As shown above, searching by the managed type can filter by namespace as well as type name. The single entries for Unity Object types, like “AppSettings” and “Hakeem”, still get their name from their native object, and in case of MonoBehaviors the GameObject they are attached to. Purely managed Objects are listed with their address value. You can also see the Unity Objects table grouping the MonoBehaviour objects by their managed type)

(A quick look at all Leaked Shell Objects. The selected one being held by a static reference in it’s own class in the manner of a typical Singleton pattern.)

Improved Comparison Mode
Problem
When comparing snapshots, it was hard to understand which objects were the same between the captures. In Base and Compare tables objects were completely indistinguishable from each other without selecting them one by one and checking their details.

How We Solved It
In this version, we've changed this so that managed objects in All of Memory view are named via their address in memory.

Additionally, when comparing snapshots from the same session, we now list native objects (or Managed UnityEngine.Objects that have a native object) individually by their instance ID in both Unity Objects and All of Memory views. This is also reflected in the Base and Compare tables, making it easier to see which object is which in each snapshot in a similar manner as the address values for managed objects.


(Above you can see an example of how the Instance ID can help you see what items in the Base and Compared tables stayed the same and which ones changed. In 1.0 all items in the bottom table would be named “DepthOfField”)

Render Texture Details
Memory Profiler now also displays the MetaData for RenderTextures - format, size, etc. similarly to the Texture object types. In conjunction with the 2023.1 version of Unity we also display additional information such as whether a resolve surface is used for the color and/or depth surfaces.



We're also continuing to improve the detailed coverage of all native and graphics related memory such as Audio system and Graphics buffers.

Bug Fixes and Improvements
We've fixed some bugs, UX issues and inaccuracies around the Select and Search in Editor/Scene/Project buttons. We've also revisited a bunch of descriptions, names and tooltips.

For the full details of all the changes, please see the Change Log.

What's Next
We are focusing on stabilization of Memory Profiler and releasing the final 1.1.0 version in the coming months.

How To Install
Go to

<YourProjectPath>/Packages/manifest.json

and add or modify the entry for the memory profiler to:

Code (CSharp):

1.     "com.unity.memoryprofiler": "1.1.0-exp.1",

We Would Like To Hear From You
We've already collected some feedback from some of you along the development of 1.1.0-exp.1 to refine some of the more complex new parts while we worked on it, but now we want to open it up to all of you to hear your feedback, while we refine it for the full 1.1.x release.

For example, we know that there are probably more usability gains to be had by a more advanced search feature but we'd love to hear what you think about it, what you're missing and what workflows you feel are underserved by it at this stage.

We’d be happy to hear your feedback, which you can provide to us directly via our public roadmap. If there is something you are unclear on and/or want to discuss, you can of course also do that via the forums, as a reply to this thread or in the Profiler Previews section of the forum.

Let’s build the tool together.

Thank you.

 

Hi @khan-amil,

Thanks for the feedback! It's good to hear that the previous UI for this was helpful. We don't currently have any concrete plans to bring back that UI but I logged your feedback through our roadmap feedback submission form so we keep track of it and can prioritize accordingly.

 

Hi Tijmen,
I hear your frustration. It just sort of feels like you're posting this into the wrong thread, because:

That has been fixed in 1.1.0-exp.1, so the very version this thread is about (and also you reported this before and while I was already fixing it and I responded back then too). Did you give that version or the currently latest release of 1.1.0-pre.1 a try?

Those are script file assets. Could it be that you have 3 equally named ones in different folders or Asset Bundles? Without more info I'm not sure if/how we could name them differently. But as for script instances, see my previous comment: 1.1.0 fixes that exact issue.

Also:

This one was also discovered before your report is already fixed in the upcoming release of 1.1.0-pre.2.

If I may ask, why not 0.7.1-preview.1?

 

Thank you for the feedback
I gather that your preference for this view would have been to

• have a Ref Count column
• have a Tree map representation of the data
• And something else?

You can sort by multiple columns by (shift+) left clicking them and but yes, right clicking now only allows to switch column visibility for the Allocated and Resident memory columns. You can't use any of those options in your snapshot because it wasn't taken from a 2023.1+ version that had the necessary extra information to be able to break down resident and allocated amounts per object.

For that also see above:

You can also not filter or group by columns anymore as you used to be able to in the old tables. (In 1.1, Searching applies a filter to everything in the description column but can't target anything else). Was that what you're looking for? If there was a ref count column, would you just need to be able to sort by it? What options specifically where you looking for?

We're still gathering the needs for search and filtering to rebuild what is necessary in a way that is more user friendly and consistent with the rest of the Unity Editor UX (e.g. Search window) than it was in those old tables, so describing which workflows and use cases of yours are underserved right now is quite valuable. I can guess them, but I don't want to rely too much on conjecture for feedback gathering, if I can avoid it

To that end:

Could you please elaborate on what columns you are missing and for what kind of workflows? And what else do you consider as a regression from that, tables wise?

That is a fair shout. There is no longer an easy way to find items with 0 or less than expected references on them at a glance. Leaked Manages Shells are now way easier to find, as they are called out as auch in the description column (All Off Memory view only for now) and can be searched for, but the same is not true for e.g. Leaked Dynamically Created Assets, which could be found before because they are asset type objects, mostly (but not exclusively) with a negative instance ID and have a ref count of 0, whereas leaked shells and other un-intentionally still referenced items have a refcount higher than that. Also, a ref count of 0 does not always equate to a leak but e.g. could be a texture that was used earlier in the scene by something that was since destroyed. It's superfluous, yes, but depending on how you look at it, not clearly "leaked". So leak detection via a snapshot rather than recording memory changes over time is a bit murky.

But back to the ref count column: Particularly in the All Of Memory table, what the ref count should be for each item is a bit less clear (e.g. Untracked amounts, Native > Reserved, some native Subsystems could look like they are unused). In some cases there wasn't yet any logic in the package to tie e.g. NativeCollection backing NativeAllocations back to managed objects holding e.g. a NativeArray in their fields (though the snapshot not containing enough data to conclusively find all of these and not false flag an Unsafe > Native Allocation as having 0 references is a bit of an issue of trustworthy numbers here), and in case of Native Allocations tied to Native Objects, the data is there but not yet processed to sum up the ref counts.

And to be honest, I was hoping we'd have a more dedicated view for seeing what holds what in memory up waaaaaay earlier, so when it came to taking a long hard look at how we can trim the old columns down to a clear and precise minimum that reduces confusion, horizontal screen real-estate and data issues as mentioned above, I made a call that maybe should have been revisited when that dedicated view, through a series of hard prioritizations, got shifted further and further down the backlog. My mistake might have also been that I have not yet given up on that view, so I didn't ponder the consequences of its longer absence on the evaluation of that call up till now. And I still hate adding a sub-par clutch that would become obsolete with a far better workflow that felt constantly within reach, but I might have to let go of some perfectionism here. I'll discuss this with the team.

Well, yes, they won't but

• The columns need to work for all items in the table and the table contains Textures and other objects that do have graphics memory and need that separated out from their native non-graphics memory
• That hypothetical view I've mentioned? Well yes, that could show that your MonoBehaviour is holding on to a Texture or other Graphics resources...

I've looked at that for the next version of the package. The Manager Field display in the Selection details was mostly at fault for that. It isn't async as the References, was doing some things that could be optimized (and now are), but also might have processed over 1000 fields even though it was capped to only explore 3 layers of indirection. That's now capped but if you need more data, there are "Continue..." Buttons in there.

That thing is btw way more powerful for managed memory inspection/debugging workflows than what we had in the old tables, were managed fields were mixed into the main table but couldn't really be used for searching and filtering regardless because they were in a sub group.

As I mentioned, the selection performance issue, is getting addressed. For the rest of it, while we have you engaged (I hope?), I think it'd be good to get some more context along the lines above before logging that as feedback. We do have some similar feedback but often with context lacking so that I and my colleagues have to infer it, which can sometimes make for less convincing arguments of the importance of the points raised and can dilute the solutions.