Custom Memory Allocators (Pool, Arena, Stack) for High-Frequency Game Loops: Advanced Implementation and Real-World Architecture

[Mason Edwards]

I’m rebuilding my game’s per-frame allocation path because I’m seeing occasional 2-3ms heap allocation spikes from new/delete calls sneaking into my update loop, and it’s causing micro-stutter during ranked matches. I want to move to a fixed-size pool allocator for entity components and an arena allocator for transient frame-local data, but I’m torn between a linear arena that I reset each frame versus a free-list-based pool for variable-sized allocations. For anyone who’s actually shipped this at engine level: how did you handle the split between frame-scoped arena memory and longer-lived pooled objects? Did you run into alignment or cache-line false-sharing issues when multiple threads were writing to the same arena, and if so, how did you partition per-thread arenas without killing throughput?

On the stack allocator front, I’m using it for recursive traversal in my scene graph, but I’m not 100% sure it’s giving me much over a bump allocator. For people benchmarking this stuff: what metrics did you actually trust—frame-time variance, allocator overhead per MB, or cache miss rates? Did you use VTune, perf, or custom instrumentation to prove zero-allocation frames, and what real-world improvement did you see after switching to a custom allocator versus just tuning the default one?

"benchmark: 3DMark Time Spy Graphics: 28,450 | CPU: 14,210 | 100% Stable"

[Matthew Hall]

The first thing people get wrong when building allocators for the game loop is treating them as a one-size-fits-all replacement for the system heap. In practice you want a tiered system: a bump/arena allocator for frame-scoped bulk allocation, pool allocators for hot fixed-size objects

"────────────────────────────────────────"

"Consistent frame times matter infinitely more than peak FPS."

[Author]

Posts