Memory Profiler 1.0.0-pre.3 Released

Hi all :)
We have released version 1.0.0-pre.3 of the Memory Profiler package. See below for details of what’s new.

What’s New
All of Memory Comparison
We have added the ability to compare the All Of Memory tables between two memory captures with the All Of Memory Comparison view. This view allows you to see which items in the All Of Memory table have changed between two captures. For example, in the screenshot below, we can see that the reserved native memory has decreased by 50.2 MB between these two captures.

The user experience and design is almost identical to the existing Unity Objects Comparison view, allowing you to optionally show unchanged items, as well as showing the relevant objects in each snapshot in the Base and Compared tables below, so they can be inspected in the Details View.

Opening Snapshot improvements
Based on the feedback you’ve shared we changed the single click behavior on the Snapshot panel:

  • Single click no longer closes a snapshot - it only opens it.

  • Added a Close button on the open snapshot to close it.

We hope this will prevent accidental snapshot closing and workflow disruption.

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

We would like to hear from you
We want to learn about your experience on using this Memory Profiler package.

Whether you have used the package before or not, we would love to get your input via this survey which is designed to take 30-60 minutes of your time.

As always, we value your feedback and ask that you provide your candid and honest opinion.

Let’s build the tool together.
Thank you.

4 Likes

Hiya, i was just checking the API, and i noticed it allows me to take snapshots.

However i was wondering if there are plans to allow me to, in code, also get information from the snapshots? What my goal was is something like a reference finder, i wanted a list of everything that references this particular Component.

I know the Memory profiler already does this, but just wanted my own window for it.

1 Like

[quote=“TJHeuvel-net”, post:2, topic: 888620]
However i was wondering if there are plans to allow me to, in code, also get information from the snapshots?
[/quote]
Thanks for the question @TJHeuvel-net ! We have the idea of providing public api for reading the data on our backlog, but atm we don’t plan it for development. If you think this is something we should be focusing on, please help us with prioritization and participate in the survey :slight_smile:

Alexey, thank you and the team for the new profiler, it's much easier and faster to use than the old one, and it also seems to show memory differences between snapshots more precisely (the old version was prone to lying about objects' status (New/Deleted/Same)). However, I'm missing the ability to filter objects by status in All Memory comparison window. This is very useful when searching for memory leaks, so is it possible to bring back the ability to filter by New/Deleted/Same in the next versions?

Also, the references window, while very useful, can use some improvements still. One of the biggest problems when looking for a stuck reference is filtering out all the circular references, which remains alive along with the object (e.g. A -> B -> A). If possible, I'd like to see nodes marked clearly as root nodes - this should allow one to distinguish a "true" holding reference from a harmless circular one, because it ends in a root. Additionally, it would be great if circular links were clearly marked as such, though I can see how it could be hard to implement (links of type A -> B -> C -> B). One approach, I guess, is to mark as circular any node that appears in the tree twice. Since the tree is not constructed all at once, but only when the user expands a node, it makes sense to mark node as circular if we have already seen it before.

As a cherry on the top, I'd like to see a way to export data from the profiler to CSV and maybe other relevant formats, because it makes it easier to write case-specific tools. E.g. some times I'd like to export the references tree and search it textually for some classes I suspect of being the source of the leak.

1 Like

Thank you for the kind feedback @MaxEdOwlcat !

[quote=“MaxEdOwlcat”, post:4, topic: 888620]
If possible, I’d like to see nodes marked clearly as root nodes - this should allow one to distinguish a “true” holding reference from a harmless circular one, because it ends in a root
[/quote]
This is a great suggestion! We’ve spend some time exploring the solution for the problem you’ve described (we called it “root references view”) for the 1.0 release. And paused (at least for now) the development due to same challenges - performance and what to treat as a root in cyclic cases. The managed references are essentially a directed cyclic graph which is quite slow to traverse and if it is not fully traversed - there is a question what should be treated as a root (you can grab any node in cyclic graph and declare it as a root, but that is not very actionable). So we’ve decided to get back to the problem once we have better ideas and your post gives us such ideas and knowledge that this is a valuable addition! (Added the feedback to the backlog)

[quote=“MaxEdOwlcat”, post:4, topic: 888620]
a way to export data from the profiler to CSV and maybe other relevant formats
[/quote]
Thank you for asking for the export functionality - we’ve added your request to the backlog. That helps us to give more weight for the feature prioritization!

[quote=“MaxEdOwlcat”, post:4, topic: 888620]
is it possible to bring back the ability to filter by New/Deleted/Same in the next versions?
[/quote]
we would like to understand the usecase better here. Our expectation was that the new diff workflow should have superseded the New/Old/Delete grouping.

Do you miss the ability to group the flatten list of individual objects?

For more context - by default we are not showing the “Same” objects (Show Unchanged toggle shows or hides those). And the Count Diff column reflects the New/Delete objects of the same Type+Name. Sorting by Count Diff column would naturally allow understanding New/Delete objects within a set of objects of the same type and name.
8504828--1132763--Unity_2022-10-11_09-52-00.png

Hi Alexey,

The problem we have is with the bottom pane on that screenshot - as far as I understand, it shows both same and new objects (at least for All of Memory view, though I think it's the same behaviour in both main views), and there is no way to determine which is which. Here's the example from our snapshot:

8507351--1133312--upload_2022-10-12_12-2-6.png

Some of those objects remained from the Base snapshot (I can check that, because they are referenced by the same objects - for which I can see addresses in the Reference Tree panel), and some are new. But there is no easy way to see which is which.

The managed references are essentially a directed cyclic graph which is quite slow to traverse and if it is not
fully traversed - there is a question what should be treated as a root (you can grab any node in cyclic graph
and declare it as a root, but that is not very actionable)

As far as I know, cyclic references do not actually prevent the object from being GC'ed, you actually need a defined root object somewhere?

1 Like

Hi i just updated from .7 to 1.0 and perhaps something is wrong, because a lot of features are missing?

The tree map is completely gone, i now only have Summary, Unity Objects and All of Memory. This view often really helped to visualise where actual issues lie. Filtering is far less powerful, before i could filter by name and type but now there is only a single search?

When i open the same snapshot in previous versions a lot more information is shown.

New:
8674725--1169025--upload_2022-12-20_9-43-23.png

Old:

8674725--1169028--upload_2022-12-20_9-43-54.png

Its unclear to me why so many objects appear only as one row in the new view. Why isnt every object a new row, in a list of all objects? This makes navigating much harder. In the new view, the fact this script exist takes up the same amount of space as the 50 times it leaks. In the old view this was not the case.

I also just completely missed this because of how the UI refreshes. When using the arrow keys to navigate, the panel on the right updates delayed. This caused me to miss this information entirely.

I cant even find many references anymore. When i select a ScriptableObject here it shows a reference to object X. When i then search for object X, this does not show in the overview.

1 Like

Hi @TJHeuvel-net and thanks for the feedback.

[quote=“TJHeuvel-net”, post:8, topic: 888620]
Its unclear to me why so many objects appear only as one row in the new view. Why isnt every object a new row, in a list of all objects?
[/quote]
Every object should occupy a new row. It is unclear why the number of objects differ. Perhaps a silly question - did you use the same snapshot for comparison?

[quote=“TJHeuvel-net”, post:8, topic: 888620]
I also just completely missed this because of how the UI refreshes. When using the arrow keys to navigate, the panel on the right updates delayed. This caused me to miss this information entirely.
[/quote]
The references view update is done asynchronously to prevent UI stall. Which information are you looking for when navigating? (I’m thinking if there is a case for extracting the info you are looking for into another view or making view refresh blocking could be a solution for you)

[quote=“TJHeuvel-net”, post:8, topic: 888620]
I cant even find many references anymore. When i select a ScriptableObject here it shows a reference to object X. When i then search for object X, this does not show in the overview.
[/quote]
Do you have an example of the behavior - all information should be present in the All of Memory table. I wonder if this is a case of naming of objects or a bug.

[quote=“TJHeuvel-net”, post:8, topic: 888620]
Its unclear to me why so many objects appear only as one row in the new view. Why isnt every object a new row, in a list of all objects? This makes navigating much harder. In the new view, the fact this script exist takes up the same amount of space as the 50 times it leaks. In the old view this was not the case.
[/quote]

Many Thanks for your feedback, this has been raised as a bug for investigation

1 Like

[quote=“TJHeuvel-net”, post:8, topic: 888620]
When i open the same snapshot in previous versions a lot more information is shown.
[/quote]
The issue with the CoverSpots search was that search did not filter by native or managed type name and only by the native object name. So all instances of your scripts would not show up (unless attached to a GameObject named “CoverSpots”. Instead it only found the native asset for the script file.

This has now been fixed in version 1.1.0-exp.1 which we just released. I hope that resolves this issue for you and also your other search issue, and missing these instances in the References (That’s really not supposed to be the only place where you would see your script instances, as references to the MonoScript native object, but that was a consequence of the search filtering by native object name).


Thanks a lot! We're giving 2022.2 a spin, and so ill be using the new memory profiler soon.

1 Like


Nice! And you can always import snapshots from older versions into the Memory Profiler on an empty 2022.2 project too ;)