📝 Lesson 4.3: Allocations, GC, and Benchmarking

How the GC Works

The garbage collector automatically reclaims heap objects that are no longer referenced. It's generational, based on a key observation: most objects die young (temporary variables, short-lived results), while a few live long (caches, singletons).

Because Gen 0 is cheap, short-lived garbage is inexpensive to collect. The trouble comes from volume and from objects that live just long enough to be promoted.

Why Allocations Cost

Allocating memory itself is fast (basically bumping a pointer). The cost is what comes after: every allocation brings a future collection closer. When the GC runs, it does work proportional to the live objects — and may briefly pause your threads.

💡 Keep perspective: for typical apps, the GC is excellent and you should not fight it. This lesson's techniques are for measured hot paths. The goal isn't "zero allocations everywhere" — it's "no wasteful allocations where it counts."

Hidden Allocation Sources

Many allocations are invisible in the source. Learn to spot these on hot paths:

// Allocation-heavy: a new string every iteration (strings are immutable)
string result = "";
for (int i = 0; i < 10_000; i++)
{
    result += i + ",";     // each += allocates a brand-new string
}

Reducing Allocations

A toolkit, roughly from most to least commonly useful:

StringBuilder for string building

var sb = new System.Text.StringBuilder();
for (int i = 0; i < 10_000; i++)
{
    sb.Append(i).Append(',');   // mutates one buffer instead of 10,000 strings
}
string result = sb.ToString();   // one allocation at the end

Span & stackalloc (Lesson 4.2)

Slice and parse without copying; use small stack buffers for scratch work.

ArrayPool<T> — rent instead of allocate

For temporary arrays in hot paths, rent a buffer from a shared pool and return it, instead of allocating a fresh array each time:

using System.Buffers;

int[] buffer = ArrayPool<int>.Shared.Rent(1024);   // reuse a pooled array
try
{
    // ... use buffer (it may be larger than requested) ...
}
finally
{
    ArrayPool<int>.Shared.Return(buffer);   // give it back for reuse
}

Other techniques

• Avoid boxing — use generics and generic APIs (Lesson 4.1).
• Hoist allocations out of loops — allocate once, reuse inside.
• Prefer struct for tiny, short-lived values where value semantics fit (Lesson 4.1).
• Cache immutable results instead of recomputing/reallocating them.

Benchmarking with BenchmarkDotNet

Timing code with Stopwatch (as we did in Module 2) is fine for a rough comparison, but it's easily misled by JIT warm-up, GC timing, and CPU scaling. BenchmarkDotNet is the industry-standard library that handles all of that — warm-up, many iterations, statistics, and allocation measurement — automatically.

# Add the package to a Release-mode console project
dotnet add package BenchmarkDotNet

Mark methods with [Benchmark] and add [MemoryDiagnoser] to report allocations:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[MemoryDiagnoser]                        // also report allocations & GC
public class StringBenchmarks
{
    private readonly int[] _numbers = Enumerable.Range(0, 1000).ToArray();

    [Benchmark(Baseline = true)]
    public string Concatenation()
    {
        string result = "";
        foreach (int n in _numbers) result += n + ",";
        return result;
    }

    [Benchmark]
    public string StringBuilder()
    {
        var sb = new System.Text.StringBuilder();
        foreach (int n in _numbers) sb.Append(n).Append(',');
        return sb.ToString();
    }
}

// In Main:
BenchmarkRunner.Run<StringBenchmarks>();

Reading the Results

BenchmarkDotNet prints a table. A simplified example for the two methods above:

How to read it:

• Mean — average time per operation (lower is better).
• Ratio — relative to the baseline; 0.17 means ~6× faster.
• Allocated — memory allocated per operation (from [MemoryDiagnoser]). Here the StringBuilder version allocates ~180× less — the concatenation created thousands of throwaway strings.

💡 The optimization loop: measure → find the hot spot → optimize it → measure again. Never skip the final measurement — some "optimizations" make things slower, and only data will tell you.

Exercise & Quiz

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

BenchmarkRunner.Run<SumBenchmarks>();

[MemoryDiagnoser]
public class SumBenchmarks
{
    private readonly int[] _numbers = Enumerable.Range(0, 1_000_000).ToArray();

    // TODO: [Benchmark(Baseline = true)] LinqSum
    // TODO: [Benchmark] LoopSum
}

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

BenchmarkRunner.Run<SumBenchmarks>();

[MemoryDiagnoser]
public class SumBenchmarks
{
    private readonly int[] _numbers = Enumerable.Range(0, 1_000_000).ToArray();

    [Benchmark(Baseline = true)]
    public long LinqSum() => _numbers.Where(n => n % 2 == 0).Sum();

    [Benchmark]
    public long LoopSum()
    {
        long total = 0;
        foreach (int n in _numbers)
        {
            if (n % 2 == 0) total += n;
        }
        return total;
    }
}

Summary

📚 Additional Resources

• Garbage collection fundamentals — Microsoft Docs
• BenchmarkDotNet — official site
• ArrayPool<T> — API reference

🚀 What's Next?

That completes Module 4 — you can reason about memory and prove performance! In the final module, we make code adaptable and well-architected. First: Lesson 5.1: Attributes and Reflection, inspecting and using types at runtime.