Definition of GC.Alloc in Profiler

What specifically is the row "GC.Alloc" in Unity's profiler?



Edit: Yes, I can already make lots of educated guesses - I'm asking for a canonical, *specific* definition. Thanks!

 

GC.Alloc means that during the run time your code (or something in the API) allocates this much of the managed memory.
This can cause problems later (that's why it has the row in the profiler), because when the Garbage Collector runs, it tends to slow down or even hang your game.
It is always a good idea to try to write your game allocation free, which means you avoid APIs and techniques which result in allocation on said managed memory.

It is important that there is no exact science to know how much allocation 'is fine' during a game run time, it depends on many things. Usually (!) the one-time small allocations are fine but heavy allocations or allocation in a loop are very bad and almost surely need to refactor.

 

You are describing what the "GC Alloc" column means, which can be attributed to any row in the profiler's output. For example, in my screenshot above, we can see 6.5kB of heap allocation happening inside of the Dictionary<> constructor.

I am asking what the GC.Alloc ROW in the profiler means. Why is there a row, as if it's a method, that has its own entry? When and why does that happen instead of the allocations just being attributed to some existing method (row) as usual?

Completely understood. I am asking about the GC.Alloc row itself.

 

That's actually a good question. I'd wager that it's the memory manager allocating more heap space. However, that shouldn't happen unless it already determined there wasn't enough space *after* a garbage collect. And then you'd expect to see that show up in the profiler as well. Perhaps it's a wrapper that abstracts the concept of checking for space, collecting, checking for space again and finally allocating if needed? Out of curiosity, was this a deep profile? If not, maybe you could try that and see how far the GC.Alloc() rabbit hole goes.

 

Ah, got you, sorry about that.

I believe that's because the hierarchy there is a representation of a call-stack and it's more clear on this way. But I'm not 100% sure in this one, so I may be wrong.

 

Yes, this was already deep, unfortunately.

 

I've just been wondering the same thing and worked it out after a little Googling and playing around:

When deep profiling is not enabled The GC.Alloc row entry is used as a catch-all for allocations performed under the stack level it is at. If you want to see where the allocations actually come from you'll need to enable Deep Profiling which can be done as follows:

• Editor: If you're profiling the editor you can select 'Deep Profile' and it will recompile and work magically when you next play.
• Desktop Standalone: If you're profiling a standalone desktop build (macOS, Linux or Windows) you can't control the 'Deep Profile' setting from within the editor (hence it is sort of greyed out in the UI). However, you can enable it by starting up your app from the command line with the argument -deepprofiling. For example, open the build folder for your game in a terminal and enter the following:
  • Windows: MyAwesomeGame.exe -deepprofiling
    
  • macOS: MyAwesomeGame.app/Contents/MacOS/MyAwesomeGame -deepprofiling
• Other Platforms Standalone: No idea! See this thread for more discussion on deep profiling on other platforms.

 

@MartinTilo Hi, there, I followed your explanation on GC.Alloc and here's the output from my session:



Does this mean that this particular GC.Alloc is emitted by the profiler or my code? If my code, then how to find which method it originated from

Thanks,
S.

 

@MartinTilo - Nothing here helps explain why I'm seeing severals kilobytes of cg.alloc data in an empty unity scene.
This makes it difficult to find which class is calling cg.alloc every few seconds. We're running into a problem where this cg.alloc is consuming the memory to a point where the application would crash with no errors or logs.

More or so - I created an empty unity project and ran from empty scene upon startup - I occasionally find 40 bytes of gc.alloc block in the threaded stack. Still can't understand why Unity, under the hood, would continue to produce garbage collection from an empty clean project state.
Using v2021.3.14f1

 

The screenshot above was ran from Unity Editor - I compiled the app and found the culprit. Still confused as to why I was unable to find more information about this garbage allocation inside the Editor, when I found the answer from the build instead?