Efficiency of the .NET garbage collector

Question

OK here's the deal. There are some people who put their lives in the hands of .NET's garbage collector and some who simply wont trust it.

I am one of those who partially trusts it, as long as it's not extremely performance critical (I know I know.. performance critical + .net not the favored combination), in which case I prefer to manually dispose of my objects and resources.

What I am asking is if there are any facts as to how efficient or inefficient performance-wise the garbage collector really is?

Please don't share any personal opinions or likely-assumptions-based-on-experience, I want unbiased facts. I also don't want any pro/con discussions because it won't answer the question.

Thanks

Edit: To clarify, I'm basically saying: No matter what application we write, resource critical or not can we just forget about everything and let the GC handle it or can't we?

I'm trying to get an answer on in reality what the GC does and doesn't and where it might fail where manual memory management would success IF there are such scenarios. Does it have LIMITATIONS? I don't know how I could possibly explain my question further.

I don't have any issues with any application it's a theoretical question.

Answer 1

Is efficient enough for most applications. But you don't have to live in fear of GC. On really hot systems, low latency requirements, you should program in a fashion that completely avoids it. I suggest you look at this Rapid Addition White Paper:

Although GC is performed quite rapidly, it does take time to perform, and thus garbage collection in your continuous operating mode can introduce both undesirable latency and variation in latency in those applications which are highly sensitive to delay. As an illustration, if you are processing 100,000 messages per second and each message uses a small temporary 2 character string, around 8 bytes (this a function of string encoding and the implementation of the string object) is allocated for each message. Thus you are creating almost 1MB of garbage per second. For a system which may need to deliver constant performance over a 16 hour period this means that you will have to clean up 16 hours x 60 minutes x 60 seconds x 1MB of memory approximately 56 GB of memory. The best you can expect from the garbage collector is that it will clean this up entirely in either Generation 0 or 1 collections and cause jitter, the worst is that it will cause a Generation 2 garbage collection with the associated larger latency spike.

But be warned, pulling off such tricks as avoiding GC impact is really hard. You really need to ponder whether you are at that point in your perf requirements where you need to consider the impact of GC.