If you’ve been following Go releases lately, you’ve probably noticed the steady drumbeat of performance improvements. The Go team recently published a post on allocation optimizations that deserves more attention than it’s likely to get, because it touches on something fundamental to how Go programs run.
The short version: heap allocations are expensive, and the team has been systematically finding ways to use stack allocations instead.
Why Heap vs. Stack Actually Matters
This might sound like low-level trivia, but it has real consequences for everyday Go code. Every heap allocation requires the runtime to do non-trivial bookkeeping work. On top of that, those heap objects become candidates for garbage collection — even with recent improvements like Green Tea GC, the collector still incurs overhead just by having more objects to track.
Stack allocations, by contrast, are often free or near-free. When a function returns, its stack frame is gone, and everything on it goes with it — no GC involvement whatsoever. Stack memory also tends to be hot in the CPU cache since you’re reusing the same region repeatedly.
The Constant-Sized Slice Example
The blog post walks through a concrete case that I found illuminating. Consider building up a slice inside a loop:
func process(c chan task) {
var tasks []task
for t := range c {
tasks = append(tasks, t)
}
processAll(tasks)
}The naive path here involves heap allocations as the slice grows. But if the compiler can determine the slice will only ever hold a bounded, constant number of elements, it can allocate the backing array on the stack instead. The trick is teaching the compiler to recognize more of these patterns and prove safety statically.
This is exactly the kind of optimization that’s hard to do yourself as an application developer — you’d have to pre-allocate with a known capacity, or restructure your code. Having the compiler handle it transparently is the right call.
The Bigger Picture
What I appreciate about this work is that it’s not chasing a single benchmark. It’s a category of improvement: reduce allocator pressure, reduce GC pressure, improve cache behavior. Those gains compound across an entire program.
For people building services with tight latency requirements — or Discord bots that need to handle bursts without GC pauses spiking response times — this is the kind of runtime improvement that actually shows up in production tail latencies.
Go has always had escape analysis to decide what goes on the heap versus the stack, but the analysis has historically been conservative. Expanding what the compiler can prove safe for stack allocation is essentially expanding the scope of what escape analysis can handle. That’s painstaking, unglamorous work, and it compounds nicely over time.
What to Watch For
If you profile Go applications, you’ll want to keep an eye on allocation counts as you upgrade Go versions. Programs that previously showed heavy allocation pressure in hot paths may see improvement without any code changes on your end.
The team has been shipping this across the last two releases, so if you’re still on an older version, there’s a practical reason to update beyond the usual bug fixes. Run go test -bench . -benchmem before and after — you might be pleasantly surprised.