Categories & Tags
Archive

Introducing the new Memory Profiler

March 14, 2013 in Technology by

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.

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.

Share this post

Comments (27)

Comments are closed.

14 Mar 2013, 8:04 am

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.

14 Mar 2013, 8:29 am

THANK YOU!!!!

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.

Kim Steen Riber
14 Mar 2013, 8:30 am

Hi Jashan
You can attach to the webplayer and make the detailed view from there. That will give you the usage on the player running the content. This also goes for other platforms. That should help you find the bloating assets in your build.

Fernando Zapata
14 Mar 2013, 9:43 am

Thank you for such an amazingly useful enhancement :)!

Nathan
14 Mar 2013, 9:48 am

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.

Jordan
14 Mar 2013, 10:20 am

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.

Jordan
14 Mar 2013, 10:22 am

It looks like my comment was trimmed; the buttons I have are but not (double ones) < >

Geoff
14 Mar 2013, 1:51 pm

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

Thanks

Mike
14 Mar 2013, 2:28 pm

Can you tell us how to hook up this profiler do an app running on an actual device? That would be REALLY helpful.

15 Mar 2013, 12:01 am

@geoff: if you can connect unity profiler to the player, you can get the memory results. Out of the top of my head, only Flash does not support connecting the profiler; all others do support it.

@mike: just connect the profiler as usual, see the docs. http://docs.unity3d.com/Documentation/Manual/Profiler.html

Kim Steen Riber
15 Mar 2013, 12:21 am

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

royter
15 Mar 2013, 2:46 am

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?

Victor
15 Mar 2013, 3:46 am

I still hat Unity3d’s implementation of PhysX. So restrictive and actually seems un-optimized

Victor
15 Mar 2013, 3:46 am

i mean hate. Cool profiler

Luis Carlos Correa
15 Mar 2013, 8:50 am

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.

15 Mar 2013, 7:49 pm

Jeez, why can’t we have so many good lock forwards and props as we have loosies?

Skilful2000`
18 Mar 2013, 9:46 am

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.

Peter
19 Mar 2013, 1:05 am

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.

KIm Steen Riber
19 Mar 2013, 1:31 am

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

19 Mar 2013, 3:55 pm

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.

Hugo
9 Apr 2013, 1:31 pm

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!

17 Apr 2013, 6:00 pm

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?

KIm Steen Riber
17 Apr 2013, 7:34 pm

@Dan: There are several very popular alternatives for GUI on the assetstore.

26 May 2013, 2:37 pm

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…

26 May 2013, 9:55 pm

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

28 May 2013, 8:48 pm

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:

http://answers.unity3d.com/questions/447175/audiomanager-memory-usage-on-ios.html#answer-463687

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.

Wayne Johnson
29 May 2013, 3:06 am

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.

Cheers

Leave a Reply

Comments are closed.