Official 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.

 

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

 

Thank you for the kind feedback @MaxEdOwlcat !

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)

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!

 

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.

 

Hi @TJHeuvel-net and thanks for the feedback.

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?

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)

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.

 

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

 

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).

 

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