Closures and defer: Capture, Escape, and Compiler Transforms

Closures are slow because they allocate, and defer has constant overhead you should avoid in hot code.

the supplied local closure is inlined and allocates nothing; a returned closure can allocate a record containing copied captures or pointers to shared cells. And defer has three cost regimes, not one: up to 8 straight-line defers are open-coded (inlined, effectively free); more than 8, or anything too complex, falls back to runtime-managed defers (~an order of magnitude slower per defer, no heap garbage); and a defer in a loop pays that runtime cost every iteration, with the deferred calls accumulating until the function returns. On current Go, none of these produce steady-state heap allocations — the _defer records are pooled — so the cost is time and accumulation, not garbage. The keyword's cost depends entirely on the shape of its use.