I’m trying to capture a snapshot of a running game (reports around 2.2GB in task manager), and the snapshot takes forever (approximately 30 minutes) to capture and then to load (around ~15 minutes). Also, the snapshots take like 10GB on disk, and the snapshot contains around 1 million of objects (~750k managed and 250k native ones).
Do you consider this as an expected/reasonable time for the memory profiler workflows, or is this something that you intend to work on in the future and make it considerably faster?
Speed of memory profiling is one of really important topics for us. Could you open ticket for us and attach there your compressed snapshot ? We would use it for investigation why it took so long to open, try improve code to handle it better and investigate why it taking so much on your hard drive.
I have similar issue. Capture took about 30 minutes. This was in Editor while game was running, and so I assume capturing on device could be faster due to Editor contributing a lot of allocations. But as I’m not able to run on device (separate ticket, linker crash when building Android), that’s all I have at the moment.
The larger issue is that when I then Open the capture, Unity crashes about 5 minutes into opening it. I’ve uploaded compressed capture in the ticket (500MB uncompressed size). Case 1111647
The latest memory profiler preview 4 contains a fix for a stack overflow crash, which I have also noticed and fixed locally before their fix came out.
My snapshots also take between 15-45 mins to open and diff, so I added a progress bar tracking the number of objects processed to know if the profiler is still doing something or has just frozen/hung due to some error.
Hi @G_Wojo , I recently submitted a new bug report (Case 1126009) where the memory snapshot crawling process either gets stuck or takes an unreasonably long time (I waiting 30 mins+ before force closing Unity). Just thought you would like to know in case it helps fixing and/or speeding up the snapshot crawling code.
I just submitted two bug reports related to this (1142394 and 1142384) with solutions included. The first one is when capturing a snapshot it will take a long time (depending on size) to actually start dumping the snapshot, and the fix is a patch to Unity’s fork of Mono. The second one is an optimization to the memory profiler package to speed up one of the last steps in opening the snapshots.
The second issue may be better solved by introducing a processing phase after capturing snapshots so it can be cleaned up and sorted for quick access.
Just submitted another two for processing snapshots, one for performance (1146248) and one integer overflow (1146246). This one helps with the loading when you see the progress bar at “Crawling GC handles”. My solutions are included with them as well. With all my fixes I got a snapshot that’s 117 GB large and took like 18 hours to capture, loading it didn’t take an unreasonable amount of time though.
@noio what Unity and package version are you using? If player and editor versions differ then please state both versions.
Does it take long to
capture (i.e. player freezes),
process the capture on the editor (player is unfrozen but editor isn’t or doesn’t yet show the snapshot)
or to open it once it appears in the snapshot list?
1 and 2 should be dramatically faster in +2019.3 versions, 3 has been sped up across the board (remember to update to the latest package versions, it’ll pay off) but would still be faster with +2019.3 versions due to having less superfluous native connections to crawl through.
For +2019.3 Unity versions I’d venture to say that anything beyond 5-10 minutes at any of these points or across all of them would be unreasonable (and worthy of a bug report) at this point, and even that’s somewhat conservative.
I guess 40GB of Memory used by the app being captured might mean that the capture process would need to access swap memory on most systems? I guess that could make it slower but almost an hour of waiting times still sounds too long for +2019.3 versions.
For 2018.3-2019.2 versions there is little we can do about these timings, durations south of an hour are not unheard of and it can also just have hung up at some point. We have a bug report for it but fixing it in 2018.4 in the way we did for 2019.3 is still considered too complex and risky a change for an LTS version (and the others are no longer supported).
Also, please note that the snapshot size is not very related to the amount of Memory taken up by the target of the capture since it is not a full memory dump (only the managed heap is dumped, Native Memory info is gathered and reported as data points only. In versions pre-2019.3 that info could be hugely inflated due to the way native connections were reported though). So being clear in what sizes we are talking about could be benefitial.
I’m using Unity 2019.4.6, with the latest package version available currently.
It is step 3: “opening” that took so long, and it is the dump itself that is 40GB. Maybe something went wrong during the opening, and Unity just became entirely unresponsive, I was not patient enough to find out whether it eventually opened the snapshot.
I did pinpoint the cause of the memory leak through the regular Profiler: I managed to find the exact frame where the allocations happened and figure out what caused them that way.
Glad you found the leak anyways :), still would be better if the Memory Profiler would have worked well enough to help with that.
Interesting. If you still have the snapshot and would be willing to share that with us via a bug report, we’d be very interested in checking out what too so long or if anything failed in the process of opening it.
We’d very likely only need the snapshot, which you could compress before uploading. Just let me know the issue ID, in this thread or as a pm if you do report it.
A memory leak would have crashed your editor out of memory after that duration, but please report a bug for this with the snapshot file. We should get that fixed.
