Mono Memory Has Reached 400 MB, but "Other" Is Close to 1 GB. Should We Optimize Mono First or Investigate "Other" Memory?
Our project's Mono memory has already reached 400 MB, but the Reserved Total still contains nearly 1 GB of "Other" memory, and Unity Memory Profiler cannot identify where it comes from. In this situation, should we focus on reducing Mono memory first, or should we investigate the "Other" memory before optimizing Mono?
When developers see Mono memory exceeding 400 MB , the first instinct is often to optimize garbage collection, improve object pooling, or even refactor code. However, in many projects, the largest—and most overlooked—memory consumer is not Mono itself, but the "Other" memory , which is often difficult to identify and classify. There is no universal "correct" value for Mono memory. The first step should always be determining your application's overall PSS Proportional Set Size memory budget . As a general guideline: 3 GB RAM devices: Keep total PSS around 1.3–1.5 GB . 4 GB RAM devices: Keep total PSS around 1.8–2.2 GB . Higher memory devices provide a larger budget, but it is still limited. Even on an 8 GB RAM device, if a process consistently approaches 3 GB PSS , it may still be terminated by the operating system when available memory becomes limited or if continuous memory leaks are present. Compared with Android, iOS typically requires a more conservative memory budget due to its stricter memory management policies. Once the overall PSS budget has been established, Mono, textures, meshes, audio resources, native memory, and other subsystems all compete for the same memory budget . In other words, if Mono is allowed to consume an additional 100 MB , another subsystem must typically reduce its memory usage by approximately the same amount. Therefore, whether 400 MB of Mono memory is acceptable cannot be evaluated in isolation . It should always be assessed together with the memory consumption of the entire application. If the "Other" memory has already grown to nearly 1 GB , investigating its source should generally take priority over further reducing Mono memory. A practical troubleshooting workflow is: 1. Capture a memory snapshot with Unity Memory Profiler. If the source of the memory can be identified directly, resolve that issue first. 2. If Memory Profiler cannot explain the allocation, inspect the Native Heap using UWA Gears or Android Studio. Pay particular attention to native allocations that Unity cannot categorize. 3. If you suspect the memory originates from Lua or another scripting engine, perform symbolized analysis with Perfetto. This can help identify the specific native allocation paths responsible for the memory usage. It is also important to remember that some native memory allocated by Android itself or by Unity's underlying runtime cannot always be further classified, and may therefore appear as "Other" memory . For this reason, memory analysis should not rely on a single tool. Instead, correlate results from Unity Memory Profiler , Native Heap analysis tools , and runtime memory data to build a complete picture before drawing conclusions.