.NET: What is typical garbage collector overhead?

Question

5% of execution time spent on GC? 10%? 25%?

Thanks.

Answer 1

It depends entirely on the application. The garbage collection is done as required, so the more often you allocate large amounts of memory which later becomes garbage, the more often it must run.

It could even go as low as 0% if you allocate everything up front and the never allocate any new objects.

In typical applications I would think the answer is very close to 0% of the time is spent in the garbage collector.

Answer 2

This blog post has an interesting investigation into this area.

The posters conclusion? That the overhead was negligible for his example.

So the GC heap is so fast that in a real program, even in tight loops, you can use closures and delegates without even giving it a second’s thought (or even a few nanosecond’s thought). As always, work on a clean, safe design, then profile to find out where the overhead is.

Answer 3

As others have said, it depends. But, just for your reading:

• The Amazing Speed of the .NET Garbage Collector
• The Hidden .NET Memory Allocation Cost

Also, my question to you would be - why are you worried about the overhead (or are you just curious from an academic standpoint)? If there is a specific situation that you think the garbage collector will affect the performance of your application, please ask about that situation and you may be able to get better responses. Otherwise, there are more important things to worry about (from a performance standpoint) than the garbage collector - the first being your own code/algorithms/etc.

Answer 4

Watch Red Gate's video here. The best GC explnation I've encountered with.

Answer 5

The overhead varies widely. It's not really practical to reduce the problem domain into "typical scenarios" because the overhead of GC (and related functions, like finalization) depend on several factors:

• The GC flavor your application uses (impacts how your threads may be blocked during a GC).
• Your allocation profile, including how often you allocate (GC triggers automatically when an allocation request needs more memory) and the lifetime profile of objects (gen 0 collections are fastest, gen 2 collections are slower, if you induce a lot of gen 2 collections your overhead will increase).
• The lifetime profile of finalizable objects, because they must have their finalizers complete before they will be eligible for collection.

The impact of various points on each of those axes of relevancy can be analyzed (and there are probably more relevant areas I'm not recalling off the top of my head) -- so the problem is really "how can you reduce those axes of relevancy to a 'common scenario?'"

Basically, as others said, it depends. Or, "low enough that you shouldn't worry about it until it shows up on a profiler report."

Answer 6

Yes, the Garbage Collector will spend some X% of time collecting when averaged over all applications everywhere. But that doesn't necessarily means that time is overhead. For overhead, you can really only count the time that would be left after releasing an equivalent amount of memory on an unmanaged platform.

With that in mind, the actual overhead is negative, but the Garbage collector will save time be release several chunks of memory in batches. That means fewer context switches and an overall improvement in efficiency.

Additionally, starting with .Net 4 the garbage collector does a lot of it's work on a different thread that doesn't interrupt your currently running code as much. As we work more and more with mutli-core machines where a core might even be sitting idle now and then, this is a big deal.

Answer 7

It really can vary. Look at this demonstration short-but-complete program that I wrote:

http://nomorehacks.wordpress.com/2008/11/27/forcing-the-garbage-collector/

that shows the effect of large gen2 garbage collections.