Search Unity

Here in Enterprise Support, we get to help out on many projects, with all kinds of combinations of Unity features. What we see is that 10 out of 10 games can improve their memory usage. That’s why we put together our newest best practice guide: Memory Management in Unity.

When we go on-site, profiling is always the first order of the day. Whether we’re uncovering coding patterns that add small but unnecessary burdens to the CPU or substantial issues that cause memory fragmentation and Asset duplication, profiling your game early and often is the best way to keep tabs on application health. The most successful teams profile their projects’ memory.

Memory is an exceptionally scarce resource (particularly on mobile devices with up to 1GB of memory, which represent 30% of the market today), so it is absolutely essential that you know where your memory is going and why. With memory being managed differently across platforms, it’s not always trivial to understand where memory is being consumed and what influence it has on CPU and GPU performance.

But fear not! We’ve created a new best practice guide: Memory Management in Unity. This guide introduces the wide variety of tools available for memory profiling, and dives into the details of how to use them effectively. By using the techniques in this guide in conjunction with the best practices for minimizing memory usage, you will be able to effectively identify and fix problem areas.

So you read all of the above and are still itching to dive into more juicy best practices? You’re in luck! While Memory Management in Unity is the latest installment, you can also check out all the other Best Practice Guides we’ve put together, each containing a number of tips and strategies to win back performance and make your project the best it can be:

We update and add to these guides regularly, so be sure to check back once in a while to see what has changed!

25 replies on “New Best Practice Guide – Memory Management in Unity”

I am getting the exception with the unity lib files that are compiled only at the time we make the android build. the issue is with file

Hi, Thank you so much for writing this article. Is it not recommend to write your game logic/timing inside corountine? Coroutine should be only use for system such as loading asset?

1.) THANK YOU! I’m dying for these «best practices» kind of articles/informational-tutorials. They are wonderful.

2.) Q about Unloading Scenes:
This doesn’t happen automatically? (If so, shouldn’t the documentation for LoadScene and LoadSceneAsync clarify?)

3.) How do we leave feedback for these articles in the future? (Say, once this blog post is no longer being monitored.)

4.) Have you considered hosting your docs on github like Microsoft does, to facilitate organized feedback and external contributions?

5.) Thank you again, please keep these kinds of tutorials updated! :)

Nice! We just solved some memory problems in our game. The sprites that we use weren’t being compressed because of the non-power of 2 resolutions. The solution was to put them in atlases. Even though most of the images are around the max size of the atlases (4Kx4K) the result was still 4-8x smaller memory footprint.

Heap explorer looks nice but its not released yet. And the developer is not looking for any more testers at this moment in time.

Excellent resource
It was not obvious to me for a long time that Unity.Object classes need Destroy to be called, even if there is nothing left in scope using the resource (thus no handle to get a hold of it again), to release them from memory.
It is not mentioned in the docs around Texture2D but it is mentioned with RenderTextures for example, not sure if I just missed this or the info is not clear enough in the general scripting docs. Or perhaps UnityEngine.Object is easily confused with a standard C# object?!

After going to «Memory Management in Unity» the first link in there (Managed Memory) runs into an error. The links in here are ok ;)

Comments are closed.