.NET: What is typical garbage collector overhead?

Question

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

Thanks.

Answer 1

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 by 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 2

In native C/C++ there is sometimes a large cost of allocating memory due to finding a block of free memory that is of the right size, there is also a none 0 cost of freeing memory due to having to linked the freed memory into the correct list of blocks, and combine small blocks into large blocks.

In .NET it is very quick to allocate a new object, but you pay the cost when the garbage collector runs. However to cost of garbage collection short lived object is as close to free as you can get.

I have always found that if the cost of garbage collection is a problem to you, then you are likely to have over bigger problems with the design of your software. Paging can be a big issue with any GC if you don’t have enough physical RAM, so you may not be able to just put all your data in RAM and depend on the OS to provide virtual memory as needed.

Answer 3

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.

Answer 4

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 5

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 6

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.