Skip to main content

why-its-cheaper-to-place-on-stack

It’s cheaper to place something on the stack because both allocation and deallocation are almost free in terms of CPU work, and the data tends to be cache-friendly.

1. Allocation is just pointer arithmetic​

  • The stack is a contiguous block of memory.
  • The CPU keeps a stack pointer (rsp on x86-64, sp on ARM) that marks the “top” of the stack.
  • Allocating space for locals = subtract a constant from the stack pointer.
  • Deallocating = add that same constant back when the function returns.
  • No searching for free space, no fragmentation handling — unlike heap allocators which have to track free/used blocks.

2. No explicit free calls​

  • Stack memory is automatically reclaimed when the function returns.
  • Heap memory requires explicit free()/delete or garbage collection.
  • With GC, you pay extra in CPU cycles later when the collector runs.

3. Better cache locality​

  • Stack frames are allocated contiguously in memory.
  • The CPU’s cache prefetcher works best with sequential memory access patterns.
  • Heap allocations can be scattered all over RAM, leading to more cache misses.

4. Fewer metadata overheads​

  • Heap allocators store metadata with each block (size, free flags, pointers in free lists, etc.).
  • Stack frames don’t need per-variable metadata — the compiler knows layout at compile time.

In short:

Stack = fixed-size, compile-time layout → pointer math + contiguous block. Heap = dynamic size, runtime layout → allocator bookkeeping + possible cache misses.