← Back to context

Comment by shivanshuag

4 days ago

Agreed, for most real world softwares, the cost of GC is irrelevant. But there are still some programs like databases or game engines where the cost can start adding up. That's when you measure and optimize.

Yet the three major game engines Unreal, Unity and Godot all have a GC on their infrastructure, and Capcom is quite happy with their .NET fork on RE Engine.

Also every single graphics application that uses Metal or DirectX, relies on reference counting as GC algorithm.

  • I’m sure those three engines have had no issues with performance whatsoever right?

    Oh shit…

    • Game developers are always trying to push the boundaries. The only game engines without performance issues are ones hardly being used.

    • I mean, you can always add enough triangles, shaders, entities, etc... to make any engine slow to a crawl... Anything that pushes state of the art will have more performance issues than something that doesn't.

> That's when you measure and optimize.

How do you "optimize" the GC away after you wrote your entire database server in a language that uses it?

  • Object pooling and bump allocators using persistent scratch buffers, mostly. The latter what you'd use for read buffers in I/O intensive applications like databases and the like.

  • Starting by using a GC language that is strongly typed, compiles to native code, supports value types, memory pools/arenas if required, which provides best of both worlds.

    Where GC means any kind of GC algorithm from CS point of view.

  • GC languages typically have features of the language and/or standard library that make GC the default, not the only option.

This assumes that you’re only ever running a single software at a time. Sure, 2-10x slower/memory consumption might not matter in a vacuum, but when every software is like this, you get machines that feel slower than they did 2 decades ago.