Object Pooling in AS3

If you're looking to save memory overhead and increase performance in your Flash creations then implementing the design pattern of Object Pooling is a great place to start. Object Pooling is most beneficial when the cost of construction is high or the frequency of construction is high.

 

Though it has to be known Object Pooling is not a silver bullet. There are definitely pitfalls to Object Pooling this most of all includes cleaning the Object for reuse. I'll get back to this in just a moment but first I have to talk about Object Pools generally.

 

In short an Object Pool allows you to retrieve an instance of a particular type of Object by checking it in and out of a resource pool. The concept of checking in and out resources is very consistent when using an Object Pool. Though handling the situation when a pool is empty is not.

 

There are three approaches I will talk about when handling an empty pool :

1) The Unbounded Pool

The pool has a boundless size and Objects are added as required to the resource pool on check out. This ensures that an Object will always be returned on check out.

 

2) The Capped Pool

The pool has a constant size and the resource pool is populated during the construction of the pool. This allows you to have all the memory overhead in the pool construction and not during check out. Though when check outs occur to an empty pool it won't return an Object.

 

3) The Queue Pool

The pool has a minimum size and the resource pool is populated during construction like option 1 it has the benefit of a maximum size - allowing the pool to grow. Unlike option 2 when the pool's maximum size or flood limit is reached and a check out occurs on an empty pool then this request is queued. Requests in the queue will be eventually dropped if not fulfilled within a defined timeout or alternatively resolved once an Object is checked in. This doesn't guarantee that the check out will be fulfilled by the Object Pool but does ensure that pools don't grow uncontrollably and when they reach flood limits that the next fulfilled check out should be the last.

 

Each of these approaches to controlling the resource pool size have unique benefits and the option you choose depends on how size matters :). Lets say in one scenario that Object memory allocation is inexpensive and having 1,000's to even 10,000's of Objects is no big deal then option 1 is a good choice. Especially considering it's simple and reliable. Though in another scenario where the same number of Objects are checked in as out and as a safe guard when a checkout occurs on an empty pool it can be suppressed then option 2 is a good choice. And doubly so considering a lot of the memory overhead of Object construction is on the Object Pool constructor and the pool will never grow out of your control. Though lastly if you can't suppress check outs on empty pools and the next Object checkout should be the last one and you need to limit your pool size due to the Objects being expensive then option 3 is more than likely the best approach for you.

 

Now I'll get back to Object cleaning, this sets an Object to the state it was in after construction which is important because check out is a replacement for constructing anew. The scenario when dirty Objects are added into the resource pool is often known as a cesspool and is considered an anti-pattern but honestly it's up to you to wether this worries you or not. Though in regard to Object cleaning it's also important to note this is where a clear pitfall emerges. If the process of cleaning is more expensive than construction then you should really consider not using an Object Pool.

 

If Object cleaning is important to you it gets interesting when consider the time and place to do this in your Object Pool class. It would seem logical to clean the Object within the check in method to ensure a cesspool never occurs. Though this could limit the Object Pool to containing a specific type of Object. This is because cleaning an Object is almost always subjective to type i.e. cleaning a DisplayObject is different to cleaning a BitmapData. Then thinking about this problem further the solution is "be kind rewind" - so the checkinee must clean before checkin. Problem solved.

 

And with every problem tackled there is another to solve. Creating an Object is also subjective to type due to parameters it may require in construction :( Unfortunately there isn't as ideal way to construct a Class with a dynamic number of parameters in Actionscript like function.apply offers for Functions. The simplest and most effective solution to this is once again the create process is external also. Another problem solved - hopefully that's all :)

 

So now that's enough talk on Object Pool's and hopefully it's given you some points to consider when creating your own Object Pool class. There's an example below demonstrating the Object Pool concepts I've used and discussed above and has a small performance victory. What this example demonstrates is the performance cost in reinitializing the particle effect constantly. As you will see there is quite a noticeable difference between pooling or not but when you compare one pool concept over another there's not much difference other than size handling features they offer which could save you performance.

 

If you would like to download the source code used in this example you can do so here