A rising memory graph deserves investigation, but it does not identify a leak by itself. The game may be warming a cache, reserving capacity, retaining unwanted objects, or loading increasingly expensive content. The useful question is what grows when the same operation is repeated under comparable conditions.
Imagine a costume preview menu that becomes less stable after repeatedly opening and closing it. Use the menu boundary to investigate ownership and retention. Avoid treating a single large snapshot as proof that every visible allocation should be removed.
/01
Define the point where memory should settle
Choose a fixed sequence: open the preview, select the same costume, close it, and return to an idle scene. Record the target device, build type, content selection, and number of cycles. Do not mix a menu repetition test with a tour through new levels; the latter introduces legitimate new content into the comparison.
Identify any expected warm-up behavior before drawing conclusions. If the first preview loads shared resources for later reuse, compare subsequent equivalent cycles as well as the initial one. State what is supposed to remain cached and who owns that decision. A cache without an intended lifetime or capacity rule is difficult to distinguish from accidental retention.
/02
Identify which memory category is growing
Unity’s Memory Profiler module distinguishes in-use and reserved memory and reports several categories. Preserve the counter names and units in your notes. A reduction in managed allocations during a frame does not prove that retained textures or native resources were released.
Compare the game’s symptom with the available evidence. If the operating system reports pressure while the inspected counter stays flat, widen the investigation instead of declaring the problem solved. Record measurement gaps clearly. Editor memory, a development player, and the final target process can have different overhead, so keep their results labeled rather than combining them into one unexplained graph.
/03
Compare snapshots at equivalent checkpoints
Capture a snapshot after the expected warm-up and another after repeating the chosen cycle. Unity’s Memory Profiler comparison view helps inspect differences, and its documentation warns that capture circumstances can introduce unrelated variation. Keep those circumstances as similar as practical and annotate any differences you cannot remove.
Start with the largest relevant changes, then inspect counts and references rather than only total bytes. In the costume example, repeated preview objects may remain reachable, or each visit may create a new material while the old one remains owned. A snapshot identifies a lead; connect it to a creation path and an expected release point before proposing a fix.
/04
Repair ownership instead of adding global cleanup
Find the system responsible for keeping or releasing the suspect resource. Inspect menu close, cancellation, scene exit, and interrupted loading paths. Determine whether a shared asset is still used elsewhere before destroying it. A preview may borrow an asset from a longer-lived cache while owning only its temporary instance.
Choose the smallest repair that follows that ownership rule. Do not add forced garbage collection or broad unload calls merely to make a graph fall. Such changes can introduce stalls, hide a missing reference release, or discard legitimate shared content. If pooling is intentional, verify its reuse and capacity behavior rather than requiring its memory to return to the empty-process baseline.
/05
Verify the trend and the reopened experience
Repeat the same cycle against the candidate and compare the same categories at the same checkpoints. Look for the expected stable behavior after warm-up and investigate any remaining growth. Also reopen the menu after cleanup; missing textures, delayed loading, or broken previews can reveal an overly aggressive release.
Test the cancellation path that was implicated, then run a representative longer session on the target device. Record the duration and workload actually exercised without claiming that a short run proves unlimited stability. Keep the snapshots, artifact identity, and ownership explanation together so later regressions can be compared meaningfully.
Keep this in mind
Key takeaways
- Compare repeated equivalent operations and separate expected warm-up from unexplained retention.
- Keep in-use, reserved, managed, native, and graphics measurements clearly identified.
- Fix the resource lifetime owner and verify both memory behavior and correct reuse afterward.
Sources & further reading
Consult the source documentation for the version and platform you are working with.