.NET Garbage Collector Basics and Performance Hints (2003)

If you are considering GC issues in an app, I think the reference code you should look at now is Roslyn and how it uses pooled ImmutableArrays to work with immutable collections almost without allocation overhead in most areas.

Most GC churn in most applications (I would think) is down to Linq and collection use.

https://github.com/dotnet/roslyn/blob/master/src/ExpressionE...

I wonder how much of the advice is still important with the improvements .NET GC has received over the decades [1] [2]

[1] http://scottdorman.github.io/2008/11/07/clr-4.0-garbage-coll...

[2] https://blogs.msdn.microsoft.com/dotnet/2012/07/20/the-net-f...

The optimizations improved GC performance in general reducing latency, but, the advice in the article is still good. One thing that may seem dated is the concern with Finalization, which is still a valid concern, but nowadays there are very few cases in which one needs to create a finalizer for their types.

Yes, they are all good tips. You will get the best performance if you don't touch memory at all, but that's not practical. There is always a trade-off: don't create large long-living objects mutable split them into smaller ones? But then you have more long lived objects.

Back in 2005-2006 we ran into significant issues with the GC and pinned memory related to Windows sockets when building a networked server for XMPP. I believe the GC has improved since then for that scenario, but it was a big surprise when it happened. It was a classic case of a leaky abstraction.

http://blog.jdconley.com/2006/06/how-to-build-scalable-net-s...

I was still in high school when I read that post. Thanks for writing it. Buffer pooling is still incredibly relevant in .Net (as it is in many languages).

Just for the sake of reference:

https://msdn.microsoft.com/en-us/library/system.servicemodel...

Along these same lines, Microsoft.IO.RecyclableMemoryStream is also useful.

https://github.com/Microsoft/Microsoft.IO.RecyclableMemorySt...

For those interested in more details about .NET garbage collector here is some reading.

Garbage Collection Overview

https://msdn.microsoft.com/en-us/library/0xy59wtx(v=vs.110)....

Fundamentals of garbage collection

https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110)....

Visualising the .NET Garbage Collector

http://mattwarren.org/2016/06/20/Visualising-the-dotNET-Garb...

Clr Book of the runtime : Garbage Collection

https://github.com/dotnet/coreclr/blob/master/Documentation/...

Maoni Stephen's Blog

https://blogs.msdn.microsoft.com/maoni

https://blogs.msdn.microsoft.com/maoni/2004/06/15/using-gc-e...

https://blogs.msdn.microsoft.com/maoni/2004/09/25/using-gc-e...

https://blogs.msdn.microsoft.com/maoni/2004/12/19/using-gc-e...

https://blogs.msdn.microsoft.com/maoni/2005/05/06/using-gc-e...

There is also a refactoring effort to standardize the GC<->EE interface

https://github.com/dotnet/coreclr/projects/3

I would link to the source code of the GC itself, but it's a single 35KSLOC file.

This is timely as I'm troubleshooting a .NET app with randomly long garbage collection times. I'm just the sysadmin in this scenario, without access to the code, so I'm approaching it from Splunk and AppDynamics. If anyone has suggestions beyond this article, I'd appreciate it :)

This may be of interest:

http://www.red-gate.com/products/dotnet-development/ants-mem...

That's a nice memory profiler, have good success with it. I've also used DebugDiag, https://www.microsoft.com/en-us/download/details.aspx?id=499... and plain ol' perfmon and its performance counters, to help track down GC-related issues.

Agreed. Starting point PerfMon and PerfCounters, as an addition to great suggested profilers I would also have a look at PerfView / ETW.

https://blogs.msdn.microsoft.com/dotnet/2012/10/09/improving...

This article is from 2003.

It's still solid advise, though.

I agree, but if the OP or a mod adds (2003) to the title then it's easier to realize that it's an old version. Perhaps the current version has a few more tricks. Perhaps someone makes a comparison with the current JVM garbage collector, and it would be "unfair" to compare the 2017 version of one against the 2003 version of the other.

It's ".NET" Garbage collector, not "Net".

No need to downvote, the title has been fixed. Thanks.

This is a really weird article. It manages to "cover" a huge amount of ground while simultaneously saying pretty much nothing.

It has a bunch of concrete recommendations, and its explanation of how the GC works lets you see the rationale behind those recommendations, and extend them to novel situations.

It explains the middle-age death problem, a direct consequence of the generations, by giving you a mental framework to reason about the .net GC.

I used the insights in this article to build an application server back in 2005 or so that spent about 2% of its time in GC at full load.