2
\$\begingroup\$

I've been reading about how garbage collection is a big problem when programming games using C#, Java, and the like - if you have a large amount of objects, the GC will run sporadically and scan through all the non-static objects you have, deleting them from memory as necessary. This can bog down your framerate or cause the game to crash if you've got a lot of objects.

From what I've read, the problem can be mitigated by statically declaring many objects during the game's initialization and storing them in an object pool (swapping out "active" and "inactive" static objects as needed so that the GC is never run). But I know it's also generally bad practice to use static objects (since it can become unclear what's what in memory, etc, etc) and I'm wondering if there's a middle ground.

So I guess I've really got 2 related questions:

  1. Is object pooling using static objects the best way to avoid GC?
  2. Under what circumstances should a Unity game be developed with some kind of GC avoidance in mind - when you're expecting to have 100 objects? 1000? 10000+?
\$\endgroup\$
5
  • \$\begingroup\$ The best way to avoid GC is to not use it. If you feel GC affects you in a negative way, feel free to make your game in a non garbage collected language like C/C++. \$\endgroup\$
    – Panda Pajama
    Commented Jun 1, 2015 at 23:14
  • \$\begingroup\$ Yes, I know avoiding use of GC is often best. But this does not answer my question. \$\endgroup\$
    – Mir
    Commented Jun 1, 2015 at 23:25
  • 3
    \$\begingroup\$ Using a language that Unity supports makes more sense than sacrificing that convenience for fixing an easily manageable performance issue. \$\endgroup\$
    – JPtheK9
    Commented Jun 2, 2015 at 0:23
  • 4
    \$\begingroup\$ Anecdotally, in a couple years of using Unity I've never had a problem with the garbage collector. So, just be wary of premature optimisation here - it's often a good idea to do something the most straightforward way and profile to see if it's a performance bottleneck, rather than invest a lot of time over-engineering up front for something that might not prove to be a big deal for your use case. \$\endgroup\$
    – DMGregory ♦
    Commented Jun 2, 2015 at 2:40
  • \$\begingroup\$ That's pretty much what I was thinking - just get it to work, then optimize. Even in a huge program I don't think it would be too difficult to do a find/replace of each object instantiation/destruct and overwrite them with an object pool behavior. \$\endgroup\$
    – Mir
    Commented Jun 2, 2015 at 3:09

1 Answer 1

Reset to default
3
\$\begingroup\$

If you're really hardcore and want to take the extra optimization, a static object pooler will be the best choice performance-wise. Most of the time, an instance object pooler will work perfectly. It all depends on what you're doing and what platform you're targeting. PC games usually take longer so an instance object pooler that only recycles objects for the current session will be fine - that, and PCs are much more powerful. On a mobile device, you might want to consider using static object pooler because instantiation/destroy is more expensive and sessions are shorter.

The number of objects you have doesn't matter so much as how frequently those objects get instantiated and destroyed. For anything that's redundant and created frequently, you should pool them. For example, bullets, creeps, pick-ups, etc.. By the time you have a system set up for those things, you might as well pool everything else to make your object creation more centralized but for a game that doesn't have any redundant objects that are spawned frequently, pooling is an unnecessary effort.

\$\endgroup\$
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .