If you've been working with Intermediate Languages for any amount of time you're probably aware of how expensive Garbage Collection can be. This invariably leads to discussions related to how to properly Dispose objects; which is very important; or how to "force" collection which is generally a really bad idea. I do not intend to revisit these overly blogged topics, and will assume you already understand the benefits and/or consequences of both. With that said, there is one aspect of this discussion which is not widely understood within the .NET community. Unfortunetaly, this can represent a missed opportunity for many applications suffering from collection performance issues.
Listen closely to your collegues when discussing this subject and you will likely hear them speaking of the "the" Garbage Collector (GC), and herein lies the problem. There isn't one GC, there are actually three different GC configurations, each having unique characteristics and potentially some drawbacks for certain types of applications. Lets take a look at each one and then we can see how to override the default selection made by the .NET Framework.
This GC has one heap per process and performs all collection on the applications main thread. Having multiple processors and/or cores does not change this configuration. Although not the default for any application type, it can have subtle advantages for non-graphical applications such as Consoles.
This GC has one heap per process and it has one dedicated GC thread per process. Having multiple processors and/or cores does not change this configuration. This GC is the default for Console and WinForm applications. The dedicated GC thread allows the application to remain more responsive while performing collection. For WinForm applications, this can be more pronounced as a result of windowing refresh/invalidation.
This GC has one GC heap per Processor and one dedicated GC thread per GC heap. As indicated by its name this GC is optimized for server-based applications. This provides better scalability by allowing a process to create objects in multiple heaps. This allows for better load-balancing and consequently is the default for all ASP.NET applications, including web services.
As it turns out, the Server characteristics can be really beneficial for other Server-style applications like Windows Services. Enabling this GC can be quite handy but the question is, how to know when this may be better for your application. Unfortunetally, the answer to this can be quite varied but there is one simple performance counter that may be a good signal to enable this capability. Take a look at the following Performance Counter:
This counter tells you how much time; as a percentage; your application is spending in GC (duh). If your application is averaging percentages above 20%-30% then enabling the Server GC may be beneficial for you. Enabling this or other GC modes can be done in the config file as follows:
As with anything, you need to test, test, test to ensure this provides a benefit to you. Enjoy...