In a Go benchmark, what does a for b.Loop() loop do that a for i := 0; i < b.N; i++ loop does not?

## Two problems with the classic loop The traditional benchmark shape is ```go func BenchmarkHashBlock(b *testing.B) { buf := makeBuffer(1 << 20) // expensive setup b.ResetTimer() for i := 0; i < b.N; i++ { hashBlock(buf) } } ``` and it carries two well-known hazards. The body's result is discarded, so the compiler may delete it. And the timing is only correct if the author remembered `b.ResetTimer` after the setup — and, more subtly, the whole function is re-invoked several times with an increasing `b.N` while the runner searches for a duration, so that expensive setup is paid on every one of those attempts. ## What b.Loop changes Go 1.24 added `testing.B.Loop`, used as ```go func BenchmarkHashBlock(b *testing.B) { buf := makeBuffer(1 << 20) // not timed for b.Loop() { hashBlock(buf) } // cleanup here is not timed either } ``` `Loop` returns true while the benchmark should keep iterating. Three things follow. **Elision resistance.** Arguments and results of function calls made inside the loop are kept alive, so the compiler cannot conclude that `hashBlock(buf)` is unobserved and delete it. This is the whole reason the method exists in a discussion of compiler elision: for the common case of "call this function repeatedly", it replaces the package-level sink. **Honest timing without ceremony.** The loop takes care of starting timing when iteration begins and stopping it when it ends, so setup written above the loop and cleanup written below it fall outside the measured region. You do not need `b.ResetTimer` for the ordinary case, which removes the most common way a benchmark silently charges setup to the result. **One execution of the function.** With `b.Loop`, the benchmark function body is executed once for each `-count`, and the loop internally decides how many iterations to run. With the `b.N` form the runner calls the function again and again with larger `b.N`, so any setup outside the loop happens repeatedly. For a benchmark that builds a large fixture, that alone can dominate wall-clock time of the test run. ## What it does not promise `b.Loop` keeps call parameters and results alive. It is not a general optimisation barrier for everything you might write inside the loop. If the body is inline arithmetic with no call — a bit-twiddling expression, a conversion, an index computation — its result is still unobserved and can still be removed, and you still want a package-level sink. Likewise, it does not stop constant folding: if the input is a compile-time constant, a constant is what gets kept alive. It also does not remove the need to think about inlining. A small function called inside the loop can still be inlined; you are then measuring the inlined form. That is often the honest thing to measure, but it is a decision, not an accident, and `//go:noinline` is how you make the opposite choice explicitly. ## When you still write the b.N form The method is Go 1.24 and later. A library that supports older toolchains — or a benchmark that must run under whatever version a downstream consumer builds with — still needs the `b.N` loop plus an explicit sink and `b.ResetTimer`. You will also keep the classic form when you genuinely need per-iteration control of the timer with `b.StopTimer` and `b.StartTimer` around work that must not be counted. ## The practical rule For new benchmarks on a current toolchain, reach for `for b.Loop()` first: it is shorter, it defends the common elision case for you, and it makes the untimed regions obvious by position rather than by a call you might forget. Add a package-level sink on top when what you are measuring is not a function call.