Why Stack Allocations Matter
Go developers constantly seek ways to accelerate programs without sacrificing safety or readability. Over the past two releases, the Go team has focused on reducing heap allocations, a major source of performance bottlenecks. Each heap allocation triggers a substantial code path and adds pressure on the garbage collector (GC). Even with advancements like the Green Tea GC, overhead remains significant. By contrast, stack allocations are far cheaper—sometimes free—and impose no GC burden because they are automatically reclaimed when the stack frame is popped. Stack allocations also promote cache locality, enabling rapid reuse of memory.
Heap Allocation Overhead in Slice Growth
Consider a function that collects tasks from a channel into a slice and processes them:
func process(c chan task) {
var tasks []task
for t := range c {
tasks = append(tasks, t)
}
processAll(tasks)
}At runtime, the slice grows dynamically. On the first iteration, the backing store is nil, so append allocates a new store of size 1. On the second iteration, that store is full, triggering an allocation of size 2; the old store becomes garbage. The third iteration allocates size 4, the fourth fits within the existing store (no allocation), the fifth allocates size 8, and so on. While the doubling strategy eventually reduces allocations, the early “startup phase”—when the slice is small—incurs multiple heap allocations and produces temporary garbage. If the slice rarely grows large, this waste becomes even more pronounced.
Stack Allocation of Constant-Sized Slices
To mitigate such overhead, the Go compiler now detects slices whose maximum size is known at compile time and allocates their backing store on the stack. For example, if you know a slice will hold at most 100 tasks, you can write:
tasks := make([]task, 0, 100)If the capacity (100) is a constant, the compiler may allocate the backing array on the stack, provided the slice does not escape (i.e., its address is not passed to functions that cannot inline it). This eliminates heap allocations entirely, along with the associated GC pressure. The stack allocation is essentially free and extremely cache-friendly.
Escape Analysis and Inlining
The key enabler is the compiler’s escape analysis. When a slice is allocated with a constant capacity and never escapes, the compiler places its backing store on the stack. Inlining often helps keep objects non-escaping by reducing function call boundaries. Recent Go releases have improved escape analysis and inlining heuristics, allowing more slices to stay on the stack—especially those with small, fixed sizes.
Practical Strategies for Stack Allocation
Developers can actively encourage stack allocation by following these practices:
- Pre-allocate with constant capacity: Use
make([]T, 0, N)whereNis a compile-time constant. This signals the compiler that the maximum size is fixed. - Use arrays for truly fixed-size collections: If you never need dynamic resizing, a fixed-size array (e.g.,
[100]task) is always stack-allocated when non-escaping. - Keep slices local: Avoid returning slices to callers or storing them in heap-allocated structures unless necessary.
- Exploit inlining: Write small helper functions that process slices; if they are inlined, the slice may remain on the stack.
Benchmark Illustration
A simple benchmark comparing heap vs. stack allocation for a 100-element slice shows that stack allocation can reduce allocation latency by orders of magnitude and eliminate GC scanning. The performance gain is especially visible in tight loops or frequently called functions.
Conclusion
Stack allocation is a powerful, low-effort optimization that Go developers can leverage by writing code with compile-time constant capacities and minimizing escapes. The Go compiler continues to improve at moving heap allocations to the stack, but explicit pre-allocation remains the most reliable technique. By understanding these patterns, you can write Go programs that are both faster and more memory-efficient.