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!

24 Comments

Subscribe to comments

Leave a reply

You may use these HTML tags and attributes: <a href=""> <b> <code> <pre>

  1. 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. Essentially this is true. Lond lasting coroutines with a lot of memory allocations is not good. Keep them short and simple. Instead use Update or even better a UpdateManager to handle your game logic. See details here: https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity3.html

      1. Oke. Thanks.

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

    2.) Q about Unloading Scenes: https://unity3d.com/learn/tutorials/topics/best-practices/native-memory?playlist=30089#Unloading%20Scenes
    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! :)

    1. 1.) Glad you like it!
      2.) If you look close enough, the documentation does tell you that this is the case, but we want to emphasize it again.
      3.) It’s always possible to reach out to our customer service team at https://unity3d.com/learn/support and tell them about it, but the blog is monitored for sure as well.
      4.) That’s out of the scope of this blog post, but I’m gonna forward the feedback.
      5.) We try to update them as often as possible! :)

      1. So https://docs.unity3d.com/ScriptReference/SceneManagement.LoadSceneMode.Single.html implicitly calls UnloadScene for all currently loaded scenes? That would make UnloadScene only relevant for scenarios where Additive scene loading is used? (This is what I assumed/expected, but isn’t how I interpreted the tutorial’s section on it.)

        1. Yes, but it can also be used to unload a scene completely.

      2. “Yes, but it can also be used to unload a scene completely.” — I don’t understand the distinction here. Beyond unloading a additively loaded scene(s), You’re saying I could load a single scene, and then use it to unload the single scene I have loaded, and just sit there scene-less? Is that useful? Or is there some aspect I’m missing? (Thanks for the help, btw!)

        1. In theory, you can do that, if you try to clean all the memory and want be 100% sure nothing holds on to it, you could unload a Scene. As you’d end up having no Scene and potential Screen artifacts, we do recommend to load an “empty” Scene instead and load the new content from that “empty” Scene instead.

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

    1. Yes! That’s a great way to gain back disc space and runtime memory. We might talk about atlases in this section in future: https://unity3d.com/learn/tutorials/topics/best-practices/textures#PVRTC

  4. You should mention the existence of Heap Explorer, the ultimate memory profiler, debugger and analyzer for Unity:
    https://forum.unity.com/threads/wip-heap-explorer-memory-profiler-debugger-and-analyzer-for-unity.527949/

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

  5. 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?!

    1. This is true and we should add this to the documentation, as native Asset types, such as Texture2D or RenderTextures have not only managed memory which gets garbage collected, but also a native memory which needs to be freed. This happens automatically when switching scenes synchronously or calling Resources.UnloadUnusedAssets (https://docs.unity3d.com/ScriptReference/Resources.UnloadUnusedAssets.html) but only if nothing in the Scenes hold onto it anymore, by making it DontDestroyOnLoad (https://docs.unity3d.com/ScriptReference/Object.DontDestroyOnLoad.html) for example.

    2. Does this apply to Mesh objects as well?

    1. Cheers! It’s fixed now and should be working in a couple of minutes when the cache refreshed.

  6. Managed Memory is not accessible currently.. runs into an error.

    1. You mean a link is broken? I just checked all of them, seem to work for me…

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

      2. Links to “Assets” and “IL2CPP & Mono” are working but main “Managed Memory” points to https://cms.hq.unity3d.com … instead of unity3d.com and lead to a 404 error ;)

        1. Thanks for the info. It’s fixed now and should be working in a couple of minutes when the cache refreshed.