Compiler Elision and Sinks

## The symptom You write your first benchmark for a checksum package: ```go var buf = make([]byte, 1<<20) func BenchmarkHashBlock(b *testing.B) { for i := 0; i < b.N; i++ { hashBlock(buf) } } ``` and `go test -bench=HashBlock` prints something like `1000000000 0.31 ns/op`. Two things in that line should stop you: the iteration count has hit the ceiling the benchmark runner will go to, and the per-operation time is under a nanosecond for a megabyte of input. ## Why the number cannot be real Do the arithmetic before you do anything else. One MiB is 1,048,576 bytes. At 0.31 ns per operation that is roughly 3.4 petabytes per second of throughput. Main memory on a large server delivers tens of gigabytes per second; even reading the buffer once out of L1 cache is orders of magnitude away from that. A number that is physically impossible is not a fast implementation, it is a measurement of nothing. 0.31 ns is, however, exactly what one iteration of an empty loop costs on a ~3 GHz core: one increment and one comparison, about a cycle. That is the tell — the loop ran, the body did not. ## What the compiler did Go's compiler inlines small functions. Once `hashBlock(buf)` is inlined into the benchmark, the compiler is looking at plain arithmetic over a slice whose computed value is assigned to nothing. It then applies ordinary dead-code elimination: a value that no reachable code ever reads, produced by operations with no side effects (no stores to memory that outlives the function, no channel operations, no calls it cannot see through), can be deleted. Delete the value and the operations feeding it become dead too, so the entire body disappears and the loop is left with its counter. Nothing here is a bug or an aggressive flag. It is the same optimisation that makes real Go code fast; the benchmark simply asked the compiler to compute something nobody wanted. Two preconditions matter. The call has to be inlined or otherwise transparent — if the compiler cannot see the body it must assume the call has effects and must emit it. And the function has to be effect-free — a hash that writes into a package-level table, prints, or takes a lock cannot be removed. ## Making the result observable The idiom is a package-level sink: ```go var Sink uint64 func BenchmarkHashBlock(b *testing.B) { var h uint64 for i := 0; i < b.N; i++ { h ^= hashBlock(buf) } Sink = h } ``` The store into `Sink` is observable outside the function, so the compiler must perform it; that keeps `h` live, which keeps every `hashBlock` call live. The `^=` costs one cheap ALU operation per iteration, which is noise next to hashing a megabyte. Since Go 1.24 the shorter route is `for b.Loop() { hashBlock(buf) }`. `testing.B.Loop` was designed for this: arguments and results of calls inside the loop are kept alive, so the call cannot be deleted outright, and the loop manages the timer for you. ## What does not fix it `_ = hashBlock(buf)` does not fix it — assignment to the blank identifier is defined to discard, and the compiler treats it as no observation at all. `b.ResetTimer()` before the loop does not fix it either; it resets the clock, and the clock was never the problem. Raising `-benchtime` or `-count` just repeats the empty measurement more times. ## Confirming it in thirty seconds Double the buffer to 2 MiB and re-run. Real hashing roughly doubles ns/op; an elided loop does not move, because its cost never depended on the input. Then add the sink and watch the number jump by four or five orders of magnitude. That before-and-after is the evidence you bring to a review.