Benchmarking without fooling yourself

auto t0 = std::chrono::steady_clock::now();
for (int i = 0; i < 1'000'000; ++i) {
    double r = price_of(i);      // result never used
}
auto t1 = std::chrono::steady_clock::now();

With optimisation on, the compiler sees that r is never used and price_of has no side effects, and deletes the loop. The benchmark reports a time close to zero, and a rewrite that happens to be harder for the compiler to delete looks slower. This is the most common way a benchmark lies, and it is the first thing an interviewer will look for in yours.

The fix is to make the result observable. Benchmark libraries provide a barrier for this: benchmark::DoNotOptimize(r) in Google Benchmark tells the compiler the value is used without adding real work. Accumulating results into a value you print at the end works too, if less precisely.

Cold start. The first iterations pay for page faults on freshly allocated memory, cold caches and an untrained branch predictor. Time only a few runs and you measure start-up.

Timer overhead. Reading a clock costs tens of nanoseconds through the usual system interfaces. Timing a single 30-nanosecond operation measures mostly the clock. Time a batch and divide, or use the processor's cycle counter carefully (Module 10).

Constant inputs. Calling with the same input every time lets the branch predictor learn it perfectly and keeps everything in L1. Real input is not like that. Use realistic data: a recorded feed, or a generated distribution with the same shape.

Frequency scaling and noise. CPU clock speed changes with load and temperature. Other processes share the cores and caches. Pin the benchmark to an isolated core, fix the frequency if you can, and run several repetitions.

Reporting one number. A mean hides the distribution. For latency work the percentiles are the result (Module 8): median, 99th, 99.9th, and the maximum.

Comparing different work. If the new version computes something slightly different, or skips a case, the speed-up is not a speed-up.

static void BM_Scan(benchmark::State& state) {
    auto quotes = load_recorded_quotes("feed_sample.bin");   // realistic data, loaded once
    Strategy s;
    for (auto _ : state) {
        scan(quotes, 4711, s);
        benchmark::DoNotOptimize(s);
        benchmark::ClobberMemory();
    }
    state.SetItemsProcessed(state.iterations() * quotes.size());
}
BENCHMARK(BM_Scan)->Repetitions(10)->ReportAggregatesOnly(true);

The library handles warm-up and runs enough iterations for a stable figure. You supply realistic data, keep the result alive, and report the spread across repetitions.

Then check the result some other way. Look at the generated assembly to confirm the work is still there. Run under perf stat to see whether the instruction count, cache misses or branch misses changed in the direction your explanation says they should. A speed-up you can explain from the counters is one an interviewer will believe.

A microbenchmark puts one function in ideal conditions: hot caches, no other threads, no interrupts. In production the same function runs between network reads, after other code has evicted its data. A change can win in isolation and lose in place. The final word comes from measuring the system end to end on realistic traffic, which is Module 8's subject.