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.
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.
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).
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 :)
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 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.
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...