Memory Profiler 1.0.0-pre.2 Released

Hi all :slight_smile:

We have released version 1.0.0-pre.2 of the Memory Profiler package. See below for details of what’s new.

What’s New

Tab Restructure

Unity Objects and All Of Memory Tabs
The Unity Objects and All Of Memory views have been promoted to their own tabs within the interface. These two views were previously located under a single ‘Breakdowns’ tab.

Potential Duplicates
The Potential Duplicates view has been moved to a toggle option within the Unity Objects view.

Removal Of Experimental Tabs
As outlined in a previous 0.6 release forum post , we have made the difficult decision to remove the experimental ‘Fragmentation’ and ‘Objects & Allocations’ tabs from the package. We have done extensive user testing and interviews over the past year and heard your feedback that these views can be difficult to use, unclear for many users, and often require expert domain knowledge to know what to look for. In addition, the experimental ‘Tree Map’ tab is also being removed due to architectural and performance issues and may be superseded in a future release by breakdown-specific tree map visualizations if there is sufficient demand for it.

We wish to make optimizing memory a task that is accessible to a wide range of our diverse user base. Achieving this requires better direction to potential memory issues, as well as guidance to solutions through clear user experience and high quality tooling. We believe that the simplified tab structure represents a better starting point for our ambitions for the Memory Profiler going forward.

As a result, there are now three tabs when in Single mode – ‘Summary’, ‘Unity Objects’, and ‘All Of Memory’ – and currently two tabs when in Comparison mode – ‘Summary’ and ‘Unity Objects Comparison’.

8221575--1073688--Tab Restructure.png

If you have a workflow that requires one of the removed tabs, firstly please tell us because we want to hear about it! You can use the Unity Engineering Roadmap to make an official feature request, or alternatively you can contact some of the team here on the forums. And secondly, you can install the last experimental release that includes the experimental tabs, 0.7.1-preview.1, by adding the following line to your package manifest file’s dependencies:

"com.unity.memoryprofiler": "0.7.1-preview.1"

Total Memory Reporting & Summary View

Memory reporting has been reworked to offer a clearer picture of your memory footprint by being much closer to how many operating systems work with memory. This gives you more clarity over how your application is consuming the memory resources of the target device.

This new approach is visible in the redesigned and rebuilt Summary view, as discussed below.

Memory Usage On Device
This section displays how much resident memory your application is using and its relative contribution to the total physical memory available on the target device. Resident memory is your application’s memory footprint in the device’s physical memory. It affects your application’s performance and stability, as using too much physical memory may cause memory swapping on platforms where swap memory is available, or even eviction of your application if its memory footprint becomes too high. This new section therefore gives you greater clarity over these potential memory issues.

Please note that the Memory Usage On Device section is only available for memory captures taken on 2022.1 and later.

Total Committed Memory
The Total Committed Memory section shows the size of your application’s committed memory and how it breaks down across high level categories, such as Native, Managed, and Graphics. Committed memory includes all the memory that was allocated by your application, whether it is resident in physical memory, swapped out to disk, or mapped to a file. Here you can get an overview of how your application’s memory is distributed across these high level categories.

Managed Memory
The Managed Memory section contains the same information as before, with some subtle UI tweaks and a link to inspect managed memory in the All Of Memory view.

Top Unity Object Categories
The new Top Unity Object Categories section shows you which categories of Unity Objects are the biggest contributors to your application’s committed memory, alongside a link to the Unity Objects view to inspect further. Some examples of Unity Object Categories are Texture2D, Shader, and AudioClip. Being able to see the largest Unity Object Categories at a glance can be helpful for getting a brief high-level understanding of how your application is using core Unity Engine objects, as well as quickly spotting an unexpected outlier, such as a category being larger than expected.

8221575--1073700--Top Unity Object Categories.png

Unity Objects Comparison

Building on the Unity Objects work introduced prior, we have now added the ability to compare the Unity Objects between two memory captures.

The Unity Objects Comparison view compares the Unity Objects between two memory captures and shows you the differences between them. Firstly, this allows you to quickly see which Unity Object Types, such as Texture2D or Material, have changed in their size or their count between the two captures.

Expanding a Unity Object Type shows you all the Unity Objects of that type that changed between the two captures. This allows you to determine which Unity Objects contribute to the change and by how much. When there are multiple Unity Objects with the same name, they are grouped into a single entry in the list.

Selecting one of these Unity Object groups will display the Unity Objects present in each capture in the two tables below. This allows you to investigate the details of each Unity Object present in both captures using the Details View, as shown below.

Becoming Verified

As you might have noticed from the version number, 1.0.0-pre.2, this version marks our first step towards reaching a verified ‘1.0’ status for the Memory Profiler package. The team has worked hard to reach the high standard of quality required for us to feel comfortable to move the Memory Profiler from an experimental status to becoming a fully verified package in Unity 2022.

We still anticipate some additional 1.0 pre releases (…pre.3 etc.) prior to the final release in the 2022 cycle.

Unity 2022

This also means that the Memory Profiler 1.0 will now become a 2022 package, requiring Unity 2022 or later.

To view snapshots taken in projects running on earlier Editor versions, such as 2019 LTS, 2020 LTS, or 2021 LTS, you can open the Memory Profiler in a 2022 Unity Editor and open your snapshots using the Import Snapshot functionality.

What’s Next

The team is currently working on:

  • All Of Memory Comparison.
  • Bug fixes, minor UX adjustments, and stabilization.


Please submit feature requests and feedback to the Unity Engineering Roadmap. Alternatively, you can contact some of the team here on the forums.


Thanks for sharing

Can you explain please this difference:
one place say that app use 0.5GB but another that app use more than 2

Hi @JesOb .

In that screenshot, the figure of 0.55 GB is Resident memory and the figure or 2.14 GB is Committed memory.

Resident memory is your application’s memory footprint in the device’s physical memory, displayed as a proportion of the available physical memory (3.52 GB in the screenshot). Committed memory however, includes all of the memory that was allocated by your application, whether it is resident in physical memory, swapped out to disk, or mapped to a file.

So, whilst committed memory gives you a complete picture of all of your application's allocated memory, regardless of where it currently resides, resident memory shows you how your application's memory is interacting with the operating system – specifically how much of it currently resides in the device's physical memory. This is important because high resident memory footprint can affect your application’s performance and stability. Using "too much physical memory may cause memory swapping on platforms where swap memory is available, or even eviction of your application if its memory footprint becomes too high".



I've made a diagram that might help explain how different memories are related. Or might confuse you even more :)


PS: Compressed/Swap memory on Android is vendor specific. It might be Linux zRAM or like Samsung "RAM Plus" which is an outright swap file.


Good diagram! :)
Add it to profiler window


Hey guys, we just tried 1.0.0 today and lots of devs instantly noticed the lack of tree map. This was one of the best features in the past versions since you got instant oversight of memory distribution in the game. Please try to put it back. If performance is an issue at least make it optional, I'm willing to wait a bit for it to build even tho I do not understand why is it a perf issue. If you can't do that, can you expose data so we can create tree map ourselves?


I’d also like to say that both the Tree Map and the Fragmentation view have been utterly invaluable to me and losing them makes the memory profiler a lot harder to recommend over an external tool.

The tree map was a perfect overview to quickly gauge the comparative size of assets, though it’s loss is secondary to the fragmentation view, which saved a project for me. We were having memory issues and it was entirely due to fragmentation, and that view allowed us to pinpoint the exact allocations that were causing the larger blocks of memory to walk, allowing us to allocate them early and not have them obstruct the other allocations.
Without that view I don’t know how we’re meant to solve that problem.

Yes, the view had all sorts of stuff in it and was difficult to understand—there are massive improvements to be made there—but removing it seems bizarre, I sure hope it’s coming back quickly.


I really dont know who they have been interviewing, everything i work with has exactly this sentiment. I simply cant work with this new UI, and downgraded.


Just go to package manager, and add the memoryprofiler package by name.


I am going to have to agree with the others here. The lack of a tree map instantly makes the memory profiler less valuable and more difficult to use. Everyone that uses it at our company has had the same response of confusion as to why it was removed and growing frustration over the lack of it. Please solve whatever issues that you were having and bring it back.


I force reverted back to 0.7 because of the lack of tree map. I appreciate the new features and nicer bar views, however, I feel removing the tree map and other views was arguably a terrible change. It seems to follow the typical Unity fashion of "Deprecate First. Replace Later".
I totally understand that it likely had some reasons to want to be replaced, but please do not take it away from us before having some form of replacement in beforehand, without it, the memory profiler is borderline unusable to me, as I am lacking good visualizations for what I would be looking at.
Anyone else who wants to downgrade to the currently better version, open your package manager, add by name, use com.unity.memoryprofiler with version 0.7.1-preview.1
I hope that this can be re-added in a future version, whether in it's existing state, or overhauled with better features, but the lack of it entirely makes me unable to use that current version of the package, and based on other replies here, others have the same sentiment.

My previous reply was determined to be perhaps too impassioned, so I will restate it with a little less frustration. I hope this meets this forum's standards for censorship:

This is a very destructive move to customer value.

It removes a feature that gives important clues to performance and architecture. It is very ironic, and frankly a bit embarrassing, to remove it for those reasons when it is such an essential tool for us to use for those very reasons.

It is also very disrespectful to do so with no request for comment before the fact. We are not just your users, we are your customers. It is furthermore insulting to do so and offer tepid non-assurances such as "may be superseded" and "if there is sufficient demand for it": this puts the onus on customers whose work and businesses have been damaged to start the conversation, and offers no commitment to reverse the damage, only lending a deaf ear (for all we know) to the problem.

While it is understandable and virtually certain that the was no malice involved, the deletion of a key piece of useful developer tooling seems to be all but a fait accompli at this point; team roadmaps at large corporations are not planned on a short enough timescale to be reverted short of a public outcry harsh enough to draw attention, or some other similarly noticeable shot across the bow.

This continues to fray trust in the competency and efficacy of Unity's teams to make correct product decisions. While I have nothing but respect and sympathy for the engineers working on Unity - some are even my friends - it's very difficult to receive this as anything except a unilaterally hurtful move with nearly no recourse to reverse, and in my opinion, is a sign of a broken process that this was planned, confirmed, and executed on without consideration for the needs of customers nor the negative impact it has on the usefulness of the tool.

This is a useful feature, and I believe very strongly it is a mistake to remove. I beg of you to please reverse this decision.

Thank you all for your feedback. Visualizations for this data (that meet our performance and quality aspirations) are on our list of improvements we want to make in a future version of the memory profiler. We know this is not ideal, but in the meantime if you need the treemap (or fragmentation view) you can revert to using version 0.7.1-preview.1 as suggested above.

1 Like

Hello all,
We are really sorry to hear you are dissatisfied with the removal of the Tree Map and Fragmentation view.

We agree that both those views provided a useful immediate overview of memory distribution, and we can totally hear and understand your frustration about not being able to work with them in the new Memory Profiler… and the consequences for your projects.

We constantly read the feedback you provide in this forum, and are taking what you are telling us in this thread very seriously. So, we would like to know more details about what you would need and are missing now, and specific use cases that are not covered. If any of you are up for it, we would love to get to talk individually, so you can provide us with more in-depth feedback regarding your needs and experience with the tool.

If you are interested, just let me know and I will make sure to set up some time to talk.

Thank you!