Memory in Unity introduction

To ensure your application runs with no performance issues, it’s important to understand how Unity uses and allocates memory.

Unity uses the following memory management layers to handle memory in your application:

• Managed memory: A controlled memory layer that uses a managed heap and a garbage collector to automatically allocate and assign memory.
• C# unmanaged memory: A layer of memory management that you can use with the Unity.Collections namespace, the Collections package, and via UnsafeUtility.Malloc and UnsafeUtility.Free. This memory type is called unmanaged because it doesn’t use a garbage collector to track and manage when memory stops being used, but requires your code to explicitly manage and release the memory itself, by calling Dispose on the collection or Free on memory allocated with UnsafeUtility.Malloc.
• Native memory: C++ memory that Unity uses to run the engine. It contains memory related to areas such as memory used for the assets in your project, and managers for Unity’s different native subsystems like the rendering or animation systems. In most situations, you can’t access this memory via your C# code, but because it’s usually the biggest chunk of your application’s memory footprint, it’s useful to be aware of it if you want to optimize your application’s memory usage.

Managed memory

Mono and IL2CPP’s scripting virtual machines (VM) implement the managed memory system, which is sometimes referred to as the scripting memory system. The VM offer a controlled memory environment divided into the following different types:

• The managed heap: A section of memory that the VM automatically controls with a garbage collector.
• The scripting stack: This is built up and unwound as your application steps into and out of any code scopes.
• Native VM memory: Contains memory related to Unity’s scripting layer.

Using managed memory in Unity is the easiest way to manage the memory in your application, but it has some disadvantages. The garbage collector is convenient to use, but it’s also unpredictable in how it releases and allocates memory, which might lead to performance issues such as stuttering, which happens when the garbage collector has to stop to release and allocate memory. To work around this unpredictability, you can use the C# unmanaged memory layer.

For more information on how managed memory works, refer to the section on Managed memory.

C# unmanaged memory

The C# unmanaged memory layer allows you to access the native memory layer to fine-tune memory allocations, with the convenience of writing C# code.

You can use the Unity.Collections namespace (including NativeArray) in the Unity core API, the data structures in the Unity Collections package, and UnsafeUtility.Malloc and UnsafeUtility.Free to access C# unmanaged memory.

If you use Unity’s job system, or Burst, you must use C# unmanaged memory. Additionally, to be able to use Burst you can only use the containers in the Unity.Collections namespace or types that fulfill the C# unmanaged constraint.

Unity’s native code, and sometimes its native allocators, allocate the memory that’s accessible to C# via these APIs. Because of this, tools like the Memory Profiler group C/# unmanaged memory in with the native memory.

Native memory

The Unity engine’s internal C/C++ core has its own memory management system, called native memory. In most situations, you can’t directly access or modify this memory type.

Unity stores the scenesA Scene contains the environments and menus of your game. Think of each unique Scene file as a unique level. In each Scene, you place your environments, obstacles, and decorations, essentially designing and building your game in pieces. More info
See in Glossary in your project, assets, graphics APIs, graphics drivers, subsystems, plug-inA set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
See in Glossary buffers, and allocations inside native memory. This means that you can indirectly access the native memory via Unity’s C# API and manipulate your application’s data in a safe and way, without losing the benefits of the native and efficient code that’s at Unity’s native core.

Most of the time, you won’t need to interact with Unity’s native memory, but you can check how it affects the performance of your application whenever you use the ProfilerA window that helps you to optimize your game. It shows how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating, or in your game logic. More info
See in Glossary, through Profiler markersPlaced in code to describe a CPU or GPU event that is then displayed in the Unity Profiler window. Added to Unity code by default, or you can use ProfilerMarker API to add your own custom markers. More info
See in Glossary. You can also adjust the performance of your application by changing the settings on your assets and via configurable settings for Unity’s native memory allocators. For more information, refer to Native memory allocators.

Additional resources

• Managed memory
• Native memory
• C# unnmanaged memory