Are there any cases where I should not use object pools but instead rely on Instantiate and Destroy? (Or more generally, outside of Unity, creating objects on a per-instance basis instead of with a pool)?
\$\begingroup\$
\$\endgroup\$
1
asked Mar 17, 2016 at 16:01
-
\$\begingroup\$ Is there a specific problem you're trying to solve with this question? \$\endgroup\$– TetradCommented Mar 17, 2016 at 22:58
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
4
It depends why you were using object pooling in the first place. Pooling mainly addresses problems with objects that are expensive to construct and which benefit from locality of reference.
Whenever you have objects that aren't expensive to construct and/or don't need to have high locality of reference, there might not be a lot of benefit to using a pool, and indeed you may start to incur some disadvantages:
Pools generally work on a fixed-block-size principle, and if that fixed size greatly exceeds the number of concurrently alive instances, you're wasting memory.
Similarly, if you can't reasonably bound the maximum number of instances, you're left with either not being able to use a pool, or use one that "grows" by allocating another fixed-size block. This starts to undermine some of the initial advantages of using a pool.
If the cost of resetting a "released" slot in a pool (so it can be used by a future instance) is higher than the cost of initial construction, that's a mark against using a pool for such objects.
If you're using a pool for improved locality of reference you generally want to swap released objects with the last used slot so you have a clear separation in the pool between "alive" and "dead" slots. If the cost of that swap is high, or if some other aspect of the object semantics require the ordering within the pool to be preserved, pools might be a poor choice.
-
\$\begingroup\$ In the second bullet, you said that a growing pool would undermine the advantages of pooling. Is this an experience you had before or just a guess? \$\endgroup\$ Commented Mar 17, 2016 at 16:34
-
\$\begingroup\$ Adding another bucket to pool almost certainly means the new bucket won't be coherent in memory with the first pool, and the coherency is one reason to choose a pool in the first place. \$\endgroup\$– user1430Commented Mar 17, 2016 at 16:36
-
\$\begingroup\$ I have just finished my own object pool script for unity in c#, and I used a generic list for pools instead of arrays. And I implemented two ways of new Instantiations: prepopulation, which is the initial creation of a certain amount of objects; and autopopulation, which is the creation of a predefined amount of objects when there is no inactive objects left. So does this mean I have a bad design? \$\endgroup\$ Commented Mar 17, 2016 at 16:43
-
\$\begingroup\$ It depends on the needs your pool was written to satisfy. There are disadvantages to that approach (as there are with all approaches) but if they don't matter for your use case, that's fine. \$\endgroup\$– user1430Commented Mar 17, 2016 at 16:58
\$\begingroup\$
\$\endgroup\$
2
Yes, when you don't need it.
This means that you should use object pooling when you profile and realize that a part of your code would benefit from object pooling.
answered Mar 17, 2016 at 16:04
-
3\$\begingroup\$ Don't use it when you don't need it! Gotcha :) \$\endgroup\$– jgallantCommented Mar 17, 2016 at 16:14
-
\$\begingroup\$ Short but true. Premature optimization leads to increased complexity resulting in more development time, more bugs, less agility and sometimes even worse performance because you lose the overview of what your smart object pooling system is actually doing behind the scenes. Like creating and maintaining a pool of objects which is, after 12 rounds of refactoring, actually never used. \$\endgroup\$– PhilippCommented Mar 17, 2016 at 17:21