Why your microbenchmark lies

Why the JIT is your benchmark’s adversary

Before you write another benchmark loop, ask yourself: what does TurboFan do when it sees a computation whose result is never observed? It removes it — completely. That is the root of every trap below.

A microbenchmark is a tiny program whose output you ignore, run in a tight loop — which is exactly the program an optimising compiler is best at demolishing. TurboFan’s whole job is to remove work that does not affect observable behaviour. If your benchmark’s result is never observed, the work that produced it is, by definition, removable. The traps below are all consequences of the optimiser doing its job on code you did not intend it to optimise away.

Trap 1 — dead-code elimination (DCE)

If the loop body computes a value nothing reads, the optimiser proves the computation is observably useless and deletes it. Your “1 billion ops” benchmark becomes an empty loop — sometimes the loop itself is removed too. The fix is a black-hole sink: accumulate every result into a variable you read after the timed region (and ideally print or return), so the optimiser cannot prove the work is dead.

// LIES — result discarded, body eliminated
for (let i = 0; i < 1e9; i++) { expensive(i); }

// HONEST — sink forces the work to be observable
let sink = 0;
for (let i = 0; i < 1e9; i++) { sink += expensive(i); }
console.log(sink); // read it so DCE cannot remove the loop

Trap 2 — constant folding and loop-invariant hoisting

If the input is a literal constant, the optimiser computes the answer once at compile time (constant folding) and your loop measures nothing. If a sub-expression does not change across iterations, it is hoisted out of the loop (loop-invariant code motion) and runs once instead of N times. The fix: make inputs vary unpredictably — derive them from the loop index or a pre-generated array of random values the optimiser cannot precompute (a “blackbox” input).

Trap 3 — un-accounted JIT warm-up

The first iterations run in Ignition (interpreted), then Sparkplug, then Maglev/TurboFan once the function is hot. If you time from iteration zero, you average cold interpretation, compilation pauses, and steady-state machine code into one meaningless number — and a “fast” result may just be a benchmark too short to ever reach TurboFan. Discard a warm-up phase, then measure; or report tiers separately if you care about both start-up and steady state.

Trap 4 — OSR mid-measurement

One giant for loop can trigger on-stack replacement: V8 compiles and swaps in optimised code while the loop is still running, so the early part of the very loop you are timing runs interpreted and the rest runs optimised — a discontinuity baked into a single sample. Prefer many calls to a smaller benchmark function (which warms up the function, not one loop) over one enormous loop.

Trap 5 — GC noise in the timed region

If the body allocates, the garbage collector will eventually pause inside your measurement, attributing GC time to your code as a random spike. Either remove allocation from the timed region, or run the benchmark many times and report a robust statistic (median/min) rather than the mean, so a stray GC pause does not dominate. Report distribution, not a single number.

Trap 6 — deopts you smuggled into the timed region

console.log inside the timed loop, a try/catch that V8 will not optimise across, or a polymorphic call introduced by the harness itself can deopt the very function you are measuring — so you measure the deoptimised version. Keep the timed region pure: no logging, no exceptions, one stable shape and type, and verify with --trace-deopt that the hot function is not bailing during measurement.

Trap 7 — micro-vs-macro mismatch

Even a perfect microbenchmark answers only “how fast is this isolated pattern in a synthetic loop”. Your app runs it interleaved with other work, with cold caches, real input distributions, and GC competition — where the micro winner can lose. Microbenchmarks pick between two implementations of a known hot spot; they do not tell you the hot spot matters. For end-to-end truth use macro suites (JetStream, Speedometer) or profile the real app. For honest micro numbers, use a harness built to defeat these traps: tinybench or mitata handle warm-up, sinks, and statistics for you.