Benchmarking .NET Code Correctly With BenchmarkDotNet

A Stopwatch around a loop doesn't measure your code — it measures your code plus JIT warmup plus GC noise plus whatever else the OS felt like doing that second.

Twice now, this book has told you to "measure, don't guess," and pointed at this exact lesson. Advanced Part III's LINQ performance lesson said struct-enumerator boxing "matters most on genuinely proven hot paths" and pointed here for the tool to prove it. The previous lesson's whole honest caveat rested on the same idea: apply zero-allocation techniques only where measurement, not intuition, says they're earned. It's time to deliver on that promise properly.

Here's the trap nearly every developer falls into at least once: wrap a Stopwatch around a loop, run it once, and trust the number. That number is almost always lying to you — not through any fault of your code, but because of exactly how .NET itself executes that code the first few times.

In this lesson, you'll learn precisely why naive timing is unreliable, meet BenchmarkDotNet — the tool the .NET community actually uses for this — and learn to read its output, including the allocation numbers that let you directly verify whether a "zero-allocation" rewrite actually reduced allocations.

What Is It?

The Simple Explanation

Microbenchmarking is the disciplined practice of measuring how long a small, isolated piece of code takes to run — accurately enough that the number actually reflects the code, not the noise around it. BenchmarkDotNet is the standard, open-source .NET library the community has settled on to do this correctly, because doing it correctly by hand is genuinely harder than it looks.

The Technical Definition

BenchmarkDotNet is a NuGet package that, given a class with methods marked [Benchmark], generates a separate, isolated console application per benchmark, runs it through a proper warmup phase, executes many iterations, applies statistical analysis to the results, and reports the outcome in a formatted table — including, when a memory diagnoser is enabled, the exact number of bytes allocated per operation. It exists specifically to eliminate the sources of measurement error that make ad-hoc Stopwatch timing unreliable, which is worth understanding in detail before looking at the tool itself.

Why Does It Exist?

The Problem — three genuine sources of noise

The Solution

BenchmarkDotNet exists to systematically eliminate all three sources of error: it runs a dedicated warmup phase long enough to reach steady-state (Tier 1) performance before recording anything, runs many iterations and reports statistical spread (not just a single number), and isolates each benchmark in its own process to reduce cross-contamination from unrelated work. It turns "I measured it once and it took 40ms" — a genuinely unreliable claim — into a statistically defensible statement about actual, steady-state performance.

Big Picture

How It Works — a complete worked example

A classic, genuinely instructive comparison: naive string concatenation in a loop versus StringBuilder — a comparison Intermediate-tier readers have heard the conclusion to before, but never actually watched get measured.

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[MemoryDiagnoser]
public class StringBuildingBenchmarks
{
    [Params(100, 1000)]
    public int Count;

    [Benchmark(Baseline = true)]
    public string NaiveConcatenation()
    {
        string result = "";
        for (int i = 0; i < Count; i++)
            result += i.ToString();
        return result;
    }

    [Benchmark]
    public string StringBuilderConcatenation()
    {
        var sb = new StringBuilder();
        for (int i = 0; i < Count; i++)
            sb.Append(i);
        return sb.ToString();
    }
}

public class Program
{
    public static void Main(string[] args) =>
        BenchmarkRunner.Run<StringBuildingBenchmarks>();
}

Run this as a Release-mode console application (BenchmarkDotNet insists on this — a Debug build's disabled optimizations would make the whole exercise meaningless), and BenchmarkDotNet takes over: it discovers the [Benchmark]-attributed methods, runs each through pilot iterations to determine an appropriate iteration count, executes a proper warmup phase for each, then the actual measured iterations, and finally prints a results table.

Reading the output table

A BenchmarkDotNet results table's columns each answer a different question — here's what each one tells you, without inventing specific numbers as if from a real run:

• Mean — the average time per operation across all measured iterations. This is usually the headline number, but never the only one worth reading.
• Error — the half-width of a confidence interval around the mean; roughly, "how much this mean could plausibly be off by." A large Error relative to the Mean is a signal the measurement is noisy and the result should be treated cautiously.
• StdDev — the standard deviation across iterations; how much individual runs actually varied from each other. A small StdDev relative to the Mean means the measurement was consistent and trustworthy; a large one means something (GC, system noise, or genuine variability in the code itself) is disturbing the result.
• Allocated — the memory allocated per single operation, from the [MemoryDiagnoser] attribute. This is the column that directly answers the question the previous lesson's whole toolkit exists to address: did a rewrite actually reduce heap allocation, and by how much?

For this specific comparison, the well-established, widely-documented expectation — not a specific invented number, but the shape of the real, repeatedly-observed result — is that StringBuilderConcatenation shows a dramatically lower Mean and a dramatically lower Allocated value than NaiveConcatenation, and the gap widens as Count grows. That's because naive string concatenation with += allocates a brand-new string on every single iteration (strings are immutable — every concatenation is a full copy), while StringBuilder grows an internal buffer and allocates only occasionally, when that buffer needs to expand.

Real-World Example — verifying the previous lesson's rewrite

Here's the payoff for everything this Part has built toward: benchmarking the previous lesson's log-line parser rewrite, exactly the kind of comparison the previous lesson's own honest caveat demanded before trusting the rewrite at all.

[MemoryDiagnoser]
public class LogParsingBenchmarks
{
    private const string SampleLine =
        "2026-08-31T10:15:00Z|WARN|OrderService|Order 4821 exceeded retry limit";

    [Benchmark(Baseline = true)]
    public LogEntry ParseWithSplit() => ParseLogLine(SampleLine);

    [Benchmark]
    public LogEntryView ParseWithSpans() => ParseLogLineSpans(SampleLine);
}

With [MemoryDiagnoser] enabled, this benchmark's Allocated column gives a direct, honest answer to the question "did the span-based rewrite actually help?" — rather than trusting the reasoning alone. This is exactly the discipline Mistake 2 of the previous lesson called for: verify allocation reduction directly, rather than assuming a rewrite that looks more efficient actually is more efficient in practice.

Analogy

Under the Hood

Common Confusion

1. "A Stopwatch is fine as long as I run the loop enough times"

Looping many times inside one Stopwatch.StartNew()/Stop() pair helps with JIT warmup somewhat (later iterations in the loop do benefit from Tier 1 promotion), but it still gives you one aggregate number with no visibility into variance, no isolation from GC pauses landing mid-run, and no allocation data at all. It's a meaningful improvement over a single cold call, but it's still missing the statistical rigor and memory diagnostics that make BenchmarkDotNet's results trustworthy enough to act on.

2. "Mean is the only number that matters"

A low Mean next to a huge StdDev or Error is a result you shouldn't trust without further investigation — it might mean the environment was noisy during the run, or that the code's performance is genuinely inconsistent (perhaps due to occasional GC pauses of its own). Always read Mean alongside its spread, not in isolation.

3. "Benchmarking and profiling are the same thing"

They answer different questions, and this course draws that line precisely in the next lesson: benchmarking compares two specific, isolated candidate implementations head-to-head; it doesn't tell you where your real, running application actually spends its time. Finding that out is profiling's job — up next.

Common Mistakes

Mistake 1 — Benchmarking a Debug build

Running dotnet run against a Debug configuration and trusting the results — Debug builds disable many JIT optimizations, so you're measuring a version of the code that will never actually run in production.

Always build and run benchmarks in Release configuration — BenchmarkDotNet will actively warn or refuse to run otherwise, precisely because Debug numbers are meaningless for this purpose.

Mistake 2 — Letting the JIT optimize away the very thing you're trying to measure

A benchmark method whose result is never used or returned can, in some cases, have its work eliminated entirely by aggressive JIT optimization — you'd end up benchmarking nothing at all and not realize it.

Always return the computed value from a [Benchmark] method (as every example in this lesson does) — BenchmarkDotNet's infrastructure is specifically designed to consume that return value in a way that prevents this class of dead-code elimination.

Mistake 3 — Comparing benchmark results across different machines or runs without noting the environment

Treating an absolute Mean value (e.g., "40 microseconds") as a universal constant that means the same thing on a laptop, a CI runner, and a production server.

Use benchmark results primarily for relative comparison — "Approach B is roughly 3x faster than Approach A, on this machine, right now" — which is far more portable and defensible than trusting an absolute number in isolation.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've learned why naive timing lies, and how BenchmarkDotNet fixes it. Let's confirm it sticks.

You now have the tool to measure, not guess — exactly what two earlier lessons in this book promised you'd get here. Last stop in this Part: finding where your real application actually spends its time and memory in the first place.