Object Pooling

[meanderingleaf]

So, as far as I can tell, the typical way to do an object pool is to create a bunch of objects ahead of time, and reuse them throughout the rest of the game, reviving dead ones as needed. Of course, this means that enough objects need to be made ahead of time so that when a new one is needed, there is a dead one to be revived.

 

I've done a pool before where I will revive if there is a dead object, and make a new one if not. Perhaps its my laziness kicking in here, because I don't really want to estimate at how many objects I will need in a particular game.

 

I can see some drawbacks in extra code in an update function that looks odd, and also the impact on gameplay of making a new object at runtime. Should I be sticking with only the prefilled pools, or is the 'elastic' approach acceptable too?

[playtwice]

A poolmanager should be able to create objects when required as this is less error prone. I usually do some pre-fills depending on the game, usually when I'm concerned about lag during the main loop. Object creation is pretty fast though so for most games this is probably not needed.

[ozdy]

I once shot myself in the foot with object pooling, as the HaXe GC was constantly firing on my allocated pool nodes as it couldn't understand those shouldn't be considered for GC and constantly traversed them  (That's for C++ target, as HaXe doesn't have own gc for JavaScript, but the point remains the same - double check if you really need it!)

[meanderingleaf]

Ouch, that is killer. And here I thought the goal was to free up that step. Never considered that just letting the GC do its work might be a good way to go as well.