Performance Analysis: Comparing Interactive and Low Latency GC Strategies in .NET

The .NET Runtime can run with different GC flavors. The following article does a good job in explaining the options: Low Latency GC in .NET 3.5 by Sasha Goldshtein.

Comparing the two modi with a sample application

I was curious about how the different modi affect the time spent by the Garbage Collector. I therefore created a sample app with two identitical methods. The methods allocate several thousand string objects. In my sample app I call each method 10000 times in a loop with the difference that I use GCLatencyMode.LowLatency for one loop and GCLatencyMode.Interactive for the other loop. Here is my sample code:

public static void DoMemoryActions()
  GCSettings.LatencyMode = GCLatencyMode.LowLatency;
  for (int i = 0; i < 10000; i++)
  GCSettings.LatencyMode = GCLatencyMode.Interactive;
  for (int i = 0; i < 10000; i++)

The two methods – MyBusinessMethod1 and MyBusinessMethod1a – have an identical implementation. I created two identical methods with a different name in order to distinguish them when analyzing the GC activity.

Based on the description of how LowLatency should work I expected the GC not to kick in as frequently for the method calls in the first loop compared to the second loop where I use Interactive (which is the default mode). Analyzing the GC Suspension Time however showed just the opposite:

More GC Activations in LowLatency Mode
More GC Activations in LowLatency Mode

LowLatency mode caused the GC to run 3 times as often as in Interactive mode. The average GC time on the other side was 40% higher on average for the GC run in Interactive mode. In my example – Interactive would be the right choice as 7 seconds less are spent by the Garbage Collector.


Many developers probably don’t know about the option to change the GC Strategy during runtime – at least that is true for workstations. There are more settings that can be changed to change the behavior of the .NET Garbage Collector. Its good to know that they exists and how they affect the runtime behavior. I do recommend to run some tests with different settings. The right choice strongly depends on the type of application.

Andreas Grabner has 20+ years of experience as a software developer, tester and architect and is an advocate for high-performing cloud scale applications. He is a regular contributor to the DevOps community, a frequent speaker at technology conferences and regularly publishes articles on You can follow him on Twitter: @grabnerandi