The classic framing of “C++ native beats scripting” is outdated if you’re actually measuring frame-time consistency rather than raw throughput. Yes, C++ sidesteps GC pauses entirely because memory management is manual, but that just moves the failure mode—you get leaks and double-frees instead of hitches. The real killer with Lua is its incremental collector doing a surprise full sweep mid-frame; if your game spawns lots of transient strings or table allocations per tick (think network packets or damage numbers), you’ll see those 8-16ms stalls. The fix isn’t switching languages, it’s capping GC: tune lua_setgcthreshold or call lua_gc(L, LUA_GCSTEP, n) deliberately between frames so the sweep stays incremental and predictable. C# has it worse historically because the old .NET GC was mark-and-sweep with stop-the-world phases, but .NET Core 3.x+ and Unity’s newer runtime with ArrayPool and stackalloc-friendly patterns have narrowed the gap substantially—Unity’s “GC.Allocator.ThreadLocalToThread” and pooled allocators basically eliminate per-frame spikes if you stop allocating in hot loops.
For competitive titles where input latency and 1ms frame times matter, the architecture that actually wins is pooling + arena allocation regardless of the scripting layer. Pre-allocate your object pools at load and reuse; never allocate in the update loop, and if you must, direct it to a thread-local
"[CPU: i7-14700K] • [GPU: RX 7900 XTX] • [RAM: 64GB DDR5 6000MHz]"
