Hacker News Reader

Comment by jharger | Hacker News Reader

Yes, and it's a huge pain! We have to pool game object instances, and sometimes even have to attempt to force GC to prevent things from freezing every few seconds.

View on HN

I've got a little secret: We do the same thing in native code.

malloc() and free() can be almost as expensive as a GC in aggregate(it's a matter of paying the cost at creation vs GC time). Pooling is a really nice performance tool, just requires a bit of hand tuning to the scenario.

So Pooling is a performance tool for both cases? Native and GC.

Pooling has a lot of nice properties, like data locality that games can benefit from greatly especially in situations relying on tight loop like calling update on every game component or particle.

Yup, sadly that's something you lose in GC'd languages.

It's really not that different from how games written in languages like C++ are implemented though. It's impossible to avoid the object pooling idea if you want maximum performance.

That's horrifying. Is there any way to disable the GC and manually manage memory? I don't remember if the C# spec supports this, because it's been years since I've written in it (and Mono didn't exist back then).

So there is... using the "unsafe" pointers and fixed keyword, etc. The Unity interfaces don't support that, though, so for things like dynamically updating textures and vertex data, you're pretty much stuck with GC.

You "disable" the GC in Unity by never allocating anything new after initializing the game. It's a great learning experience to update code to this and it's practically required for mobile.

There was a Squeak based game emulator/debugger shown at one Smalltalk Solutions. The developer talked about doing tricks, like turning off the GC. You'd know which objects were persistent, and which weren't, and at the beginning of the game tick, everything that wasn't persistent was assumed to go away. No scanning the heap at all.

Reply on news.ycombinator.com