I’ve been trying to sort out a periodic microstutter in my game that’s been driving me nuts for a while, which occurs both in the editor and in builds.
As I was learning to use the profiler, I noticed that I get periodic spikes of 4 to 8 ms from garbage collection, which I figured might be the culprit. These spikes persist even in a scene with nothing in it.
Is this normal? I am on Unity 2020.3.15f2 LTS, in case that’s relevant.
Use the profiler to figure out what is generating garbage.
The garbage collection is listed under TimeUpdate.WaitForLastPresentationAndUpdateTime in the profiler. I don’t really know what that means.
But like I said, it happens even in an empty scene, so I’m quite certain it’s not caused by any scripts I’ve written.
Yes but it could be a package you have installed.
I haven’t installed any packages, so that seems unlikely. My project is a default URP project.
But am I correct to assume, judging from your responses, that periodic 4-8ms GC spikes are in fact not normal behaviour?
URP is a package.
By default Unity installs a whole bunch of packages.
You can see in the profiler what is generating garbage and how much
Ok, but those are all script updates though. My test scene is fully empty, and the only thing that the profiler reports to be spending time on GC is an entry in the PlayerLoop named TimeUpdate.WaitForLastPresentationAndUpdate.
The weirdest part is that, since the scene is empty, the profiler lists no garbage as being generated at all in the player loop, but somehow Unity is still periodically wasting time on cleaning it up.
Observe:
Go to player settings and untick Use incremental GC and see if this goes away.
That actually totally worked, and the microstutter seems to be mostly gone too now.
Thanks a bunch!
Does this also happen in a built game? This is probably expected in the editor where all sorts of editor components (including the profiler) are generating garbage, but the GC shouldn’t get triggered without allocations in the player.
In this case it may be useful to have the checkbox only effect the build and not the editor?
If you do allocate memory, in that you’d see vastly different behaviour in the player vs the editor. It’d be hard to decide which bucket your game falls into.
I’d instead suggest profiling only the builds instead, as profiling the editor in any non-trivial case will get affected by editor itself.
Actually, it never occured to me to check a build, so I just ran a couple of builds with and without the checkbox enabled, and yeah the microstutters seem to only happen in the editor. So it’s probably an editor component that was generating the garbage. I don’t think I can get any GC statistics for a built game (or at least I don’t know how), but it sure seems that way.
Which is fine, a little bit of stuttering in the editor is no big deal.
I’m confused.
I misremembered, lol. I thought I’d checked, but I guess I forgot.
Anyway, I just found out that you can profile built games, and yes I can confirm that the GC spikes don’t occur in built games. Mystery solved!
Speaking of gc, @Tautvydas-Zilys are there any plans to finally replace old imgui? Drawing top of game bar takes 1ms, zoom slider alone (that 95% of users never use) 0.2ms not to mention gc allocs.
#Edit forgot to mentioned that’s during playmode
I have no idea, I don’t really work on the editor.
This
You should get in the habit of only testing performance in builds, and only investigating performance issues found in builds, unless the issue is so bad in the editor it is slowing your work progress. Using the Editor’s Play mode, you’re sharing the same main thread between your game, the Editor, the frequent updates of all the Editor windows, etc. Also your code when run in the Editor is optimized for debugging, not optimized for performance like in a build. So performance issues within the Editor don’t really mean anything as far as how players will experience your game.
Issue is so bad in the editor it is slowing your work progress.
Yes for me entering playmode is the issue, even without domain reload it takes like 15 seconds and thats just putting me out of flow.
Btw, you can see the editor allocations when you switch the target from Play Mode to Editor. Additionally, some Editor Only allocations are filtered out by default (like null component checks). That can be changed via the three dot menu in the hierarchy views toolbar.
Also, Hierarchy only ever shows the allocations made on the thread it currently shows, defaulting to the main thread. Other threads can have allocations in them too though. So you can switch through them in hierarchy or go to timeline view to look for magenta colored GC Alloc samples.
Also the memory profiler module shows a summary of all allocations in the frame across all threads.
