Performance Profiling & Benchmarking

By the end of this lesson you'll be able to measure how fast your code runs instead of guessing — timing a block with Stopwatch, comparing two approaches fairly, writing rigorous benchmarks with BenchmarkDotNet, watching memory allocations, and knowing when to reach for a full profiler. The golden rule of all performance work: measure first, optimise second.

1. Measure, Don't Guess: Stopwatch

The fastest way to answer "how long does this take?" is System.Diagnostics.Stopwatch. Stopwatch.StartNew() creates and starts a high-resolution timer in one line; you do your work, call .Stop(), then read .ElapsedMilliseconds. Crucially, do not use DateTime.Now for this — it can jump backwards (clock changes, NTP syncs) and has poor resolution. Stopwatch is monotonic and built for exactly this. Read this worked example, run it, then you'll time your own block.

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        // Stopwatch is a high-resolution timer — far more accurate than
        // DateTime.Now for measuring elapsed time. StartNew() creates it
        // AND starts it in one line.
        var sw = Stopwatch.StartNew();

        // === The block of work you want to time ===
        long total = 0;
        for (int i = 0; i < 10_000_000; i++)
            total += i;                 // some real work to measu
...

Your turn. The program below times a counting loop — it just needs the three Stopwatch calls filled in. Replace each ___ using the hints, then run it.

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        // 🎯 YOUR TURN — fill in the blanks marked with ___, then run it.

        // 1) Create AND start a Stopwatch in one line.
        var sw = ___;               // 👉 Stopwatch.StartNew()

        // The work we want to time: count up to a big number.
        long count = 0;
        for (int i = 0; i < 5_000_000; i++)
            count++;

        // 2) Stop the clock.
        sw.___;                    
...

2. Comparing Two Approaches

A single timing in isolation rarely tells you much — what you really want is "is A faster than B?". The classic example: building a big string. Using += in a loop secretly creates a brand-new string on every pass and copies everything so far, so the cost grows with the square of the size. A StringBuilder keeps one growable buffer and appends into it. Time both side by side and the gap is dramatic — and now you can prove it rather than assert it.

using System;
using System.Diagnostics;
using System.Text;

class Program
{
    static void Main()
    {
        const int N = 50_000;

        // --- Approach A: build a string with += in a loop ---
        // Each += makes a BRAND-NEW string and copies everything so far,
        // so the work grows with the square of N. This is the slow trap.
        var swA = Stopwatch.StartNew();
        string a = "";
        for (int i = 0; i < N; i++)
            a += "x";               // allocates a ne
...

Now you try. Time both approaches yourself and print them so you can compare. Fill in the three ___ blanks — two stopwatch calls and one result read:

using System;
using System.Diagnostics;
using System.Text;

class Program
{
    static void Main()
    {
        const int N = 30_000;

        // 🎯 YOUR TURN — time BOTH approaches and compare them.

        // --- Approach A: += in a loop (the slow way) ---
        var swA = Stopwatch.StartNew();
        string a = "";
        for (int i = 0; i < N; i++)
            a += "*";
        // 1) Stop stopwatch A.
        swA.___;                    // 👉 Stop()

        // --- Approach B: StringBui
...

work();                       // 1) warmup — let the JIT compile it
var sw = Stopwatch.StartNew();
for (int i = 0; i < 1000; i++) work();   // 2) many runs, not one
sw.Stop();
double perRun = (double)sw.ElapsedMilliseconds / 1000;  // 3) average

3. The Right Tool: BenchmarkDotNet

BenchmarkDotNet is the industry-standard .NET benchmarking library, and it handles every pitfall above for you. You tag methods with [Benchmark], mark one as the Baseline, and call BenchmarkRunner.Run<YourClass>(). It warms up the JIT, runs each method many times, discards outliers, computes the mean and standard deviation, and prints a clean comparison table. You read it, not write the timing scaffolding yourself. (BenchmarkDotNet needs a real .NET project, so study this worked example here, then run it in your own project with dotnet run -c Release.)

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Text;

// Run benchmarks with:  dotnet run -c Release
// NEVER benchmark in Debug mode — the JIT skips optimisations there,
// so the numbers are meaningless.

[MemoryDiagnoser]              // also report allocations + GC, not just time
public class StringBenchmarks
{
    private readonly string[] _words = System.Linq.Enumerable
        .Range(0, 1000)
        .Select(i => $"word{i}")
        .ToArray();

    // Basel
...

Notice what the table gives you that a bare Stopwatch can't: a Mean (in microseconds, far finer than ms), a Ratio against the baseline so the relative speed is obvious at a glance, and — because we added [MemoryDiagnoser] — the memory each method allocated. That last column is the one beginners forget.

4. Allocations & GC Pressure

Speed isn't the only cost. Every object you create on the heap is future work for the garbage collector (GC) — the part of .NET that reclaims memory you're no longer using. Allocate a lot and the GC runs more often, and a GC pause briefly freezes your program. Under load that's frequently what makes a "fast" method slow in production. Add [MemoryDiagnoser] to a benchmark and watch the Allocated and Gen0 columns: a method that's twice as fast but allocates ten times more memory may lose once real traffic hits it.

using BenchmarkDotNet.Attributes;

// The Allocated and Gen0 columns from [MemoryDiagnoser] often matter
// MORE than Mean. Every allocation is future work for the garbage
// collector — and under load, GC pauses are what slow real apps down.

[MemoryDiagnoser]
public class AllocationBenchmarks
{
    private readonly int[] _data = System.Linq.Enumerable
        .Range(0, 1_000_000).ToArray();

    // Allocates an iterator + delegates behind the scenes.
    [Benchmark(Baseline = true)]
    public
...

using System;
using System.Diagnostics;

class Program
{
    // A reusable helper: time any block of code, print the result.
    // Run the block ONCE to warm up (let the JIT compile it), then time it.
    static void Time(string label, int repeats, Action work)
    {
        work();                          // warmup run — JIT-compile the method
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < repeats; i++)
            work();                      // the timed runs
        sw.
...

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        // 🎯 MINI-CHALLENGE: which way of summing an array is faster?
        // 1. Build an int[] of 5,000,000 numbers (fill it in a loop).
        // 2. Approach A — sum it with a for loop. Time it with a Stopwatch.
        // 3. Approach B — sum it with LINQ's .Sum(). Time that too.
        //    (Add 'using System.Linq;' at the top, then call data.Sum().)
        // 4. Print BOTH timings AND which approach
...