Hi there,
I am living with my spike nightmare quite a while. Now they make me crazy and I decided to look where they coming from. Now I see with the Profiler in the “Hierarchy” that I have spikes from EditorLoop and lucky me I saw I can change this “Hierarchy” to “Timeline” which is exposing a bit more details. So I see there are “Scripting Threads” where one of them has a big processing time causing those spikes with the “GC.Collect” detail
Now I went to get more information’s what is causing this garbage collecting to maybe fix it/change my code. Therefore I tried the “Deep Profile” to collect more details. But everytime I have the “Deep Profile” enabled, I have no more spikes and this garbage collection.
Does any one have an idea? Would be much appreciated
Hi there,
please excuse me if you are already aware of it, but just to clarify: there isn’t necessarily one single call that triggers the GC.Collect. While there is very likely one GC.Alloc that triggers it, because it asks for more memory than is immediately available, chances are there is a set of them.
Additionally, there may be GC.Allocs that happen as part of the EditorLoop. So to get a better picture of what’s happening, you should probably switch the Profiler target to “Editor”, or better still, if your main concern is the performance in the runtime, make a development build and profile that. There’s also a build option to enable Deep Profiling in the build I’d that would become necessary to find your issues.
However, Deep Profiling also has some performance overhead, which as you noticed can change the performance characteristics of your game in such a way that it becomes hard to find your GC.Collect spike. And if the GC.Collect doesn’t happen on the main thread, the chart isn’t going to show it under that category either, because the chart just shows the main thread timings.
You can, however, use the Memory Profiler Module to observe the amount of GC Memory to spot frames in which memory got collected or in which the heap expanded.
In the Profiler Window’s top toolbar, you can also switch on Call Stacks for GC.Alloc. With that option enabled, you can investigate the origin of the magenta GC.Alloc samples in timeline without the need for Deep Profiling. For details on that, see the manual page I linked to above.
Hi and thanks for your answer,
I tried to change from Play Mode to Edit Mode in the profiler - if this is what you mean with the Profilter target “Editor”
Now with that I see that it seems to be not recorded in the Profiler anymore.
So when you say Memory Profile Module, you mean clicking on the “Memory” in the profiler, right? Or do I need to install something on top of it? From what I see my GC Allocated in Frame is pretty low 0,9 MB
the GC used in Memory is dropping from 5GB to 4,33 GB while this spike frame where the GC.Collect is so long being processed.
Then the game is running and as soon as the GC Used Memory is almost 5GB I have again this spike with the GC.Collect taking too long.
When looking into the Memory Module details I see one big row “ManagedHeap.UsedSize” but nothing to fold out for this position to get more details.
I have no clue where this is coming from
Yes (I mentioned the module to differentiate it from the package)
There isn’t much further info in that module for your situation. The idea of using that module was to use the graphs there to spot frames with GC.Collect. to investigate the GC.Allocs, you need to look at the CPU Module and select the magenta GC.Alloc samples in Timeline view to see the Call Stacks. There is also a way to see these in Hierarchy that is explained on the Manual page.
And if GC.Collect can regularly free about 0.66 GB, then that’s a lot that was allocated and then no longer needed.