Search Unity

The new Unity 4.1 release features an updated and vastly more powerful Memory Profiler tool that provides more specific and more accurate information about game performance, both for games running within the Editor and games running directly on specific devices.

Update: The Memory Profiler described in this blog post is no longer being maintained. All work on memory profiling has moved to the new Memory Profiler package (September 4, 2019).

With the new tool, it’s much easier for developers to tackle the leaks that inevitably arise during development and that Unity’s garbage collection can’t pick up on because they relate to referenced game elements.

Gathering more detailed information

The estimate performed by the original Memory Profiler provided a good approximation of memory usage by tracking selected asset types. In the new version of the Memory Profiler however, all game objects and asset types are tracked along with several internal Unity structures. In this way, the new tool provides much more precise information about how much memory is allocated to various areas.

To provide just one example, the old tool estimated how much memory an animation used based on the various animation tracks. The problem is that such an estimate quickly becomes outdated and needs to be kept in sync. with development. In the new Memory Profiler, every allocation related to the animation is linked automatically, and the numbers shown reflect real-time memory usage on the platform.


Providing a detailed breakdown

As well as making data more accurate, tracking more memory also allows the new Memory Profiler to provide much more detailed information to the developer about how memory is used. The new tool lists each asset and its memory consumption individually allowing the user to check which ones are using more memory than they really should.

Plus, the updated Memory Profiler also provides a better system-level breakdown. Unity has a number of internal systems that use a lot of memory: for example the Shader Lab and internal file caches. Developers can now see how these internal systems affect memory usage when their game is running on the Editor, and how they use less memory or are stripped out completely when the game plays on a device.

A major ongoing project

The new Memory Profiler has been under development for some time, and a lot of preparation has gone into it as it’s something that touches on all Unity systems — everything uses memory.

For us as a company, the new Memory Profiler also provides useful information about the way that Unity uses memory which we’ve used to tweak and trim the engine in various places.

In future, we hope to further develop the tool, and our ultimate aim is to provide total transparency about where every single byte in Unity goes.

27 replies on “Introducing the new Memory Profiler”

Hi Alex,

Unfortunately procedural audio is still not quite there as a complete replacement to samples, so some memory will be required ;)

But regarding your findings, yes streaming samples do allocate a bunch of memory for stream buffers. It is recommended to only stream for quite large samples (generally music). Not just for memory reasons but also disk usage and responsiveness of playback.

This could be expressed better in the documentation, and we’ll look into that.


Hey Aras, thanks for the reply.

I was profiling on iOS (so on the player.) However, I found something interesting. It looks like if you have many small audioclips (e.g. player dialogue) that are compressed, and you select «stream from disc» as their load type, then AudioManager is internally allocating ~15Mb, presumably for some decompression buffers. Additionally, it looks like small streamed clips always have a 64kb overhead per clip, which in extreme cases, can be bigger than the MP3’d sample itself.

So, I switched all my dialog to use «Compressed In Memory», and now AudioManager seems to take 5.9Mb, which is much better. (It needs an extra .2Mb each time I play a different music track, the tracks are still streamed from disc, but that’s not unreasonable.)

It would be great to know if my findings are correct, and maybe add a build warning saying «hey, you don’t want to be streaming these assets from disc, just keep them compressed in memory» if I’m correct. But I’m fine for now. I also posted a comment here:

because comments on here probably aren’t the right place. And I’m not sure I’m smart enough to keep getting these spam protection questions right.

@Alex: are you profiling the editor or the actual player? IIRC audio manager takes 18MB in the editor only (for various audio preview textures in the inspector).

Looking at the awesome new unity profiler on iOS, it looks like AudioManager always takes 18Mb. I’m trying to squeeze a very large iOS app onto 256Mb devices, which in practice means they must take <100Mb Is there anything we can do to reduce this number? I've already tried reducing audiosources, changing compression settings, etc to see if there's any way to reduce it. Can you tell us what this value is dependent upon?

Obviously, as a former rendering programmer, I strongly believe that audio shouldn't be allowed to use ANY memory, although I also used to say the same thing about UI, and now have an iPad app in development with 100Mb of UI that CAN'T BE COMPRESSED DAMNIT OR ELSE IT RUINS THE LOOK, which is why I need some of that 18Mb…

I just attended the two-day Tokyo Unite 2013 conference. During the memory profiling talk We were told to NOT/NEVER to use OnGUI in release builds as it’s memory usage is not ideal, and that we should «use something else». We weren’t given any alternatives and I didn’t get the chance to ask after the talk.

So what should we use instead of OnGUI?

Hi Kim. Thanks for this amazing feature. I am using a lot of third party tools and now I can see where the team are missing very easily. I am testing it and enjoying the hard work!

Jashan said: «IMHO, whenever a feature is used a lot by the developers of the feature, this makes it much better much more quickly.»

Indeed, and this is one of the core reasons behind my argument that Unity should be making games and selling them like cry, epic and id have done. This increases investor confidence, developer migration and helps Unity understand why it’s wrong about a lot of it’s tools, and why that upsets developers currently.

So it’s a good start, but I hope Unity tend to use more of it’s own tools from now on.

[…] 在这里了解更多关于性能,深入了解这里的内存监视器。   […]

@ Peter: No, there is no way to dump the profile to a file. The Take Snapshot for when you want to take a sample with the new detailed memory profiler. This is a fairly heavy operation, so that is why we have a button for it.

I’m using Profiler in 3.5.7 getting data from an Android device. My question is how can I dump that data. I can see that in the Unity 4.1 version (pic posted) there seems to be a «Take Sample» button maybe to dump the data? . How about in 3.5 , any way to dump it?
Thank you.

[…] or Play-Asia, but it needs to be based in the US because I want to be able to Pre-order a 32 gig memory stick for the upcoming Ps Vita handheld, as Australia and Europe won’t be getting the 32 gig […]

Thanks for this great tool, it will immensely help developers track all issues concerning memory leakage and were they are hiding. the tool will be a massive assistance now. thanks to unity team.

Great stuff, I have one question tough, It says in the docs that the difference in memory between what XCode activity monitor and the profiler reports are due to executable code and drivers.
Does that mean that there’s nothing I can do to optimize that memory usage? My project shows a ~40MB diference.

We develop for mobile, mainly tablets and the memory profiler was simply useless for us to track and troubleshoot memory issues. We had to use the Xcode profiler to address this issues which was better but not the solution we wished. Will this new tool let you know exactly how much are you using memory on the iPADX and if you will run out of memory or unstability issues?

@Mike: yes. When your application is running on the device, you can connect to it by selecting the device in the dropdown ‘Active Profiler’ in the top bar of the profiler window.

You mention «specific devices» Will this be available for mobile devices such as iOS and Android? Or will this require desktop level GPU’s?


I know this is slightly off topic and I apologize but will the Documentation for the profiler be updated as well? The screenshot from the Unity3D Manual displays controls I don’t have (v4.0.1f2). Mainly the <> buttons for transversing frames; without them I don’t know how to view frames that are pushed off the side of the profiler during recording.

Hi Kim, this is probably the best or at least one of the best features in the profiler yet! I’ve been waiting for this one almost since the profiler came out. Thanks for the hard work and bringing this into the editor.


We needed this so bad it wasn’t funny. For mobile we were suffering from high memory usage and the previous profiler was not helpful.

Awesome! What I especially like is that you’re using the Memory Profiler yourselves to improve Unity. IMHO, whenever a feature is used a lot by the developers of the feature, this makes it much better much more quickly.

Speaking of optimization: Are you planning to improve the way assets bloating builds can be tracked down? The only approach I’m currently aware of is using the console when building a Web player. While this is nice to have, it’s sorted by «pre-compression sizes» and it can be a fairly long list. Having something similar to that integrated right into the editor with different options (uncompressed size, compressed size) might make our lifes a lot easier.

Maybe with the new memory profiler we’re actually getting quite close, though.

Comments are closed.