Simple Object Pooling in Flash

Been loving 360 Flex this year! Tyler and I finally finished our presentation, and so I had some time to write a post I’ve been meaning to.

One of the issues one comes across in building performant applications in Flash is object creation and garbage collection. Object pooling helps overcome this. Object pooling is keeping old objects around and reusing them instead of throwing them away and always creating new fresh objects.

Creating objects in Flash isn’t bad. It’s when you create hundreds or thousands of throw-away objects very quickly that this becomes a problem.

Used Pooling in Observe

For my final implementation of the Observe class I use objects to temporarily store information about hooks and observers that allows me to sort them based on order they were added. At first I thought how unfortunate that I have to create objects to do this when one of the major reasons for creating Observe is to eliminate the creation of Event objects every time a property change happens.

Fortunately I have complete control over Observe and its implementation (unlike Flash’s Event model) and I can pool these temporary objects. Setting up pooling is very simple and I’d like to demonstrate how it can be done by pretending we’re building a super-fast memory efficient best-performance tween engine. We’ll go with this use case, build pooling, and let the remainder of the tween engine be left to the imagination or as an exercise of the reader to finish.

Tweening Ultra-Speed

Our pretend tween engine is called Tweening Ultra-Speed, because that sounds super cool. Super duper cool (k, so it’s late). The biggest problem with high-peformance tween engines like GreenSock’s preventing them from pushing beyond their top speeds even further is object creation and garbage-collection. In order to create a new tween the API might look like this:

Tween.create({target: mySprite, duration: 1000, x: 10, y: 20});

No big deal, right? Unless you’re pushing the limits and creating thousands of these every second. The object being created between those parentheses is being allocated some memory and then garbage collected later. Memory builds up as thousands of these are called, then drops back down (with a noticeable pause in the animation) because the garbage collection cleans up the old objects.

How else could we do this?

We need to have objects that we can reuse. We might go specific and have a MovementTween that holds the x/y properties. We might do a size tween that holds the width/height properties. I’m going to go with generic and do a property tween for each type of property. For now, we will cover 90% + of tween use-cases with a NumberTween object.

public final class NumberTween
	public var name:String;
	public var value:Number;
	public function NumberTween(name:String, value:Number)
	{ = name;
		this.value = value;

I’m keeping it simple and not including other stuff we might need such as current value and delta value, easing, and stuff like that. Now we have a concrete object that would be used like so:

var tween:Tween = new Tween(mySprite, 1000); // let's say 1000 is the duration
tween.addProperty(new NumberTween("x", 10));
tween.addProperty(new NumberTween("y", 20));

Of course, this doesn’t solve the problem yet, but now that we have a concrete class, we can make a pool for NumberTweens. My favorite way is to add a static method on the class and using a link-list. It is very fast and light, and I think very elegant.

public final class NumberTween
	public var name:String;
	public var value:Number;
	public var next:NumberTween; // this is for the link-list. We can also use this outside the pool to link our tweens together in the addProperty calls.
	private static var pool:NumberTween;
	public static function get(name:String, value:Number):NumberTween
		var tween:NumberTween = pool;
		if (tween == null) tween = new NumberTween();
		pool =; = null; = name;
		tween.value = value;
	public static function put(tween:NumberTween):void
	{ = pool;
		pool =;

The important things to note here are the static get and put methods. You now use get to retrieve a new NumberTween instance and put to “release” it back to the pool once you’re done with it. If your pooled object points to any objects or non-mutable types (non-string/number/boolean) this could be where it gets cleaned up too (don’t keep mySprite tied in memory to a pooled Tween object). I’ve also made a method called destroy that does the same thing, puts it back into the pool. Let’s say we do something similar for our Tween class as well.

var tween:Tween = Tween.get(mySprite, 1000);
tween.addProperty(NumberTween.get("x", 10));
tween.addProperty(NumberTween.get("y", 20));

Once the tween has finished running it can call a Tween.put() on itself which might call property.constructor.put() on all of its properties. The great part for this particular scenario is that you can have NumberTween, ColorTween, BlurFilterTween, etc. for each type you want to support! Now we may be creating thousands of tweens every second but we’re recycling object instances so that object creation is limited and garbage collection isn’t slowing things down. What is it they say? “Reduce, reuse, recycle.”

This is my take on object pooling. You could create a pooling framework, but it is so simple to add pooling to a class, it doesn’t seem necessary for quick things. And this pooling would speed up tween engines that much more (at the expense of more lines of code to create a tween. There are trade-offs).

So who’s going to finish my tween engine for me?

6 Responses to “Simple Object Pooling in Flash”

  1. Paul Taylor Says:

    Tweensy, by Shane McCartney, uses object pooling, linked lists, and strongly typed tween delegates to make tweening properties very fast. I’m sure you’re familiar with it already, but if not, here’s Shane’s writeup:

    The object pool classes in Tweensy are general purpose and super easy to use outside of his projects.

  2. Marc Christie Says:

    Cool post. In the put function, don’t you want to do

    pool = tween;

    that way on the next get, this returned tween will be accessible.


  3. Jacob Wright Says:

    Paul: No, I didn’t know tweensy used all that. I’ll check it out.

    Marc: That is the point. Pooling means reusing the objects later. By setting the to pool and then pool to tween we are storing a chain of objects that can be used later, rather than always creating new objects.

  4. Paul Taylor Says:

    Oh, I thought for sure you’d have seen it.

    Shane’s got an excellent writeup on different object pooling strategies (w/ source) and their application to Flash. Check it out!

  5. Jacob Wright Says:

    I’d heard of Tweensy. Just haven’t looked into it. I did now. One difference is that he goes for easier API by using anonymous objects (e.g. {x: 10, y:20}) for the properties of a tween. Though there is pooling that can be turned on, he could take it a step further and pool the objects for tweening.

    To make a better API and reduce objects even more you could create specific types of property tweens as you need them. MoveTween could have an x and y property on it (and even handle motion blur for you). Alpha tween could just take one number for the alpha and could have logic to set visible to false if alpha reaches 0. Lots of optimizations still to be had.

  6. Gary Paluk Says:

    Hi Jacob,

    This is excellent, I was inspired to release my own object pooling classes that may be of use. They provide a more generalized way of creating pools for different types of objects whilst adding powerful abstractions of pool creation and access models. You can get the code at my blog :)