Great points so far, but I think we’re underselling how much GC strategy matters for competitive titles where consistent frame time beats peak FPS. With C#, the real killer isn’t the GC existing—it’s the generational collector chasing short-lived allocations like string concatenation in hot paths, boxing in LINQ queries, and per-frame struct copies. A single GC.Collect() call is basically a freebie for stress-testing; the problem is the automatic Gen 0/1 collections firing unpredictably. Practical fix: set the GC to WorkStation mode with concurrent collection for background threads, pool everything you can (especially strings and IEnumerable results), and profile with the memory timeline in Unity’s profiler to catch alloc-per-frame before it becomes a visible hitch. If you’re doing netcode or input handling in C#, route it through a custom allocator or use NativeArray/Unity’s new allocator API to sidestep the managed heap entirely.
For Lua specifically, the incremental GC is usually fine for gameplay scripting but can still cause micro-stutters in a 144Hz+ scenario because it runs in bounded slices per frame—if a slice overruns, you eat the cost on the next frame. I’ve seen studios switch Lua to a stop-the-world collector with manual luaGCStep() calls scheduled during load screens and menu transitions, keeping gameplay frames allocation-free. Honestly, for
