dotnet-micro-optimization

name

dotnet-micro-optimization

description

Benchmark-driven micro-optimization loop: find the fastest implementation of a hot function by measuring one-hypothesis-per-variant implementations under a benchmark harness, reading JIT/native disassembly to explain the numbers, and iterating until improvements fall below 2-3%. Use this whenever the user wants to optimize a small hot function, find the fastest implementation of something, compare implementation variants, set up micro benchmarks (BenchmarkDotNet, criterion, google-benchmark), analyze JIT assembly or machine code, vectorize a loop with SIMD/intrinsics, or asks "why is this slow" / "make this faster" at the function level — even if they never say the word "benchmark". Also use it when porting an optimization winner back into a library (runtime dispatch, correctness parity tests, before/after end-to-end measurement for a PR).

Micro-Optimization Loop

A disciplined search for the fastest implementation of a small hot function. The output is not just faster code: it is a measured, correctness-gated, disassembly-explained result with a findings log that says why the winner wins and which plausible ideas were refuted.

The single most important mindset: hypotheses are cheap, measurements decide. Roughly a third of well-reasoned optimization hypotheses turn out to be wrong (caching that loses to recomputation, wider vectors that lose to narrower ones). The loop exists to catch those cheaply instead of shipping them.

When to use / not use

Use when the hot function is already known (profiler, benchmark, or obvious algorithmic core) and is small enough to reimplement in variants — roughly one screen of code, called thousands+ times.

Do not start here when the bottleneck is unknown (profile end-to-end first) or when an asymptotic/algorithm change is still on the table (do that first; this loop tunes constants, and a better algorithm invalidates all tuning).

For .NET, do not start here when the question is "what is this code allowed to do" rather than "which variant is fastest" — buffer ownership, Span/Memory selection, stackalloc budgets, and hot-path prohibitions are standing rules, not hypotheses to measure. Use for those, and come back here once a specific function needs tuning.