Why is this an issue?

GC.Collect is a method that forces or suggests to the garbage collector to run a collection of objects in the managed heap that are no longer being used and free their memory.

Calling GC.Collect is rarely necessary and can significantly affect application performance. That’s because it is a tracing garbage collector and needs to examine every object in memory for cleanup and analyze all reachable objects from every application’s root (static fields, local variables on thread stacks, etc.).

To perform tracing and memory releasing correctly, the garbage collection may need to block all threads currently in execution. That is why, as a general rule, the performance implications of calling GC.Collect far outweigh the benefits.

This rule raises an issue when any overload of Collect is invoked.

static void Main(string[] args)
{
  // ...
  GC.Collect();                              // Noncompliant
  GC.Collect(2, GCCollectionMode.Optimized); // Noncompliant
}

There may be exceptions to this rule: for example, you’ve just triggered some event that is unique in the run of your program that caused a lot of long-lived objects to die, and you want to release their memory.

Resources

Documentation

• Garbage collection
• GC.Collect
• Garbage collection latency modes
• Garbage collection troubleshoot performance issues

Benchmarks

Each .NET runtime features distinct implementations, modes, and configurations for its garbage collector. The benchmark below illustrates how invoking GC.Collect() can have opposite effects across different runtimes.

Glossary

• Collect - if True, GC.Collect() is called in the middle of the allocation heavy Benchmark() method
• Mean
• Standard Deviation
• Allocated

The results were generated by running the following snippet with BenchmarkDotNet:

class Tree
{
    public List<Tree> Children = new();
}

private void AppendToTree(Tree tree, int childsPerTree, int depth)
{
    if (depth == 0)
    {
        return;
    }
    for (int i = 0; i < childsPerTree; i++)
    {
        var child = new Tree();
        tree.Children.Add(child);
        AppendToTree(child, childsPerTree, depth - 1);
    }
}

[Benchmark]
[Arguments(true)]
[Arguments(false)]
public void Benchmark(bool collect)
{
    var tree = new Tree();
    AppendToTree(tree, 8, 7);        // Create 8^7 Tree objects (2.097.152 objects) linked via List<Tree> Children
    GC.Collect();
    GC.Collect();                    // Move the objects to generation 2
    AppendToTree(new Tree(), 8, 6);  // Add some more memory preasure (8^6 262.144 objects) which can be collected right after this call
    tree = null;                     // Remove all references to the tree and its content. This freees up 8^7 Tree objects (2.097.152 objects)
    if (collect)
    {
        GC.Collect();                // Force GC to run and block until it finishes
    }
    AppendToTree(new Tree(), 3, 10); // Do some more allocations (3^10 = 59.049)
    AppendToTree(new Tree(), 4, 7);  // 4^10 = 1.048.576
    AppendToTree(new Tree(), 5, 7);  // 5^7 = 78.125
    GC.Collect();                    // Collect all the memory allocated in this method
}

Hardware configuration:

BenchmarkDotNet v0.14.0, Windows 10 (10.0.19045.5247/22H2/2022Update)
Intel Core Ultra 7 165H, 1 CPU, 22 logical and 16 physical cores
  [Host]               : .NET Framework 4.8.1 (4.8.9282.0), X64 RyuJIT VectorSize=256
  .NET 9.0             : .NET 9.0.0 (9.0.24.52809), X64 RyuJIT AVX2
  .NET Framework 4.8.1 : .NET Framework 4.8.1 (4.8.9282.0), X64 RyuJIT VectorSize=256