Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

MemoryProfiler: Improvement for finding memory leaks

Discussion in 'Profiler Previews' started by owenlshinyshoe, Jun 2, 2021.

  1. owenlshinyshoe


    Aug 4, 2017
    I made a modification to Memory Profiler to make it easier to find memory leaks. Here's the code in case it's helpful to anyone.

    When I'm looking for memory leaks, what works best for me is to take a snapshot in the main menu, play the game a bit, go back to the main menu, take a snapshot, and repeat that process, each time playing the game in exactly the same way, until I have 7 snapshots. Then I open the last one (snapshot 7) and look at which allocations were new in snapshots 3-6 and yet still in snapshot 7. These are the leaks.

    The allocs in snapshot 7 that were new in snapshot 1 are the game's global managers, which are fine. The allocs that were new in snapshot 2 (the first gameplay) are probably legitimate caching. The allocs that are new in snapshot 7 include legitimate things like the main menu. But the allocs that were new in snapshots 3-6 should have been deleted. If there's a leak, even a small one, I'll see allocs that are from snapshot 3, and probably see similar ones from snapshot 4, 5, and 6, since probably the same leak happens every time I play.

    Unity's Memory Profiler (I'm using 0.2.9-preview.3) comes very close to providing this with the Diff feature. So I only had to write a bit of code to extend it to get the functionality I needed. Thank you, Unity, for allowing us to see and modify the source.

    I've included my modifications here in case anyone else is interested. My installation procedure is crude:

    If you have Memory Profiler 0.2.9-preview.3 installed:
    Unzip on top of your Library\PackageCache\com.unity.memoryprofiler@0.2.9-preview.3 folder.

    If you have a different version of Memory Profiler installed:
    Unzip and into a temp folder and compare them to see the changes I made. Then apply the changes by hand to your Library\PackageCache\com.unity.memoryprofiler@x.x.x code.

    How to use it:

    1. In the Editor, open Window/Analysis/Memory Profiler.
    2. Delete your existing snapshots.
    3. Start your game
    4. In your game, go to the main menu or somewhere constant where you want to take your snapshots. I'll call it the main menu.
    5. In the Memory Profiler take a snapshot. Rename it "Snapshot-1" or something that will indicate which one it is in the sequence of snapshots.
    6. Play the game a bit in a way that you can repeat later. I play two battles with the random seed forced to 0 so it plays the same every time.
    7. Return to the main menu.
    8. Repeat steps #5-7 until you have at least 5 snapshots, ideally 7-12 snapshots.
    9. Choose Leak Analysis/Generate.
    10. Wait a few minutes while it opens each snapshot and gets data out of it. It's done when it logs "Generate Leak Data done" in the Editor console. It created the file LeakData.json in your snapshots directory.
    11. Open the last snapshot and go to the Table/AllObjects view.
    12. Find the "Snapshot" column (at the far right), right-click on it, and choose "Group".
    13. Look in any of the groupings that aren't the first two snapshots or the last one. These are the potential memory leaks.


    Attached Files:

    MartinTilo and alexeyzakharov like this.
  2. alexeyzakharov


    Unity Technologies

    Jul 2, 2014
    Thank you for sharing!
    This is really great demonstration of leaks detection workflow. Happy to see snapshot having data needed to do the analysis and generate the report!
  3. MartinTilo


    Unity Technologies

    Aug 16, 2017
    Thanks for sharing this idea. Specifically I think we'll likely look at 3 snapshot diffs as a future feature for this, which seems to be the crutial bit here (snapshot 1 as baseline, snapshot 2 with new allocations made, snapshot 3 which should be back to baseline).
    However, we need to adjust a bit of how diffs work (and the codebase already shifted quite a bit internally too) right now so taking over this code just like that won't be possible. Definitely an inspiration though. Hopefully we'll be able to provide better API hooks and export options to allow building such extensions more easily also to allow integrating them into a CI/CD setup.