Recycler Object for Object Pool Pattern

Creating or destroying an object is never free and JavaScript is no exception. Generally, the cost of creating/destroying an object in JIT-optimized JavaScript runtimes doesn't affect performance, but other languages will have a performance hit as well. The real culprit is the increase in your application's memory footprint (watch the memory tab in a developer tool while running the tests below for an illustration). This is why, in most cases, reusing a single object is much more efficient than creating new objects.

The Recycler Object Pattern (Recycler Pattern) is the first part of this two part post on the recycler pattern and object pools. A recycler object is instantiated once and reused. It should have an initialization function to set internal variables and a recycler function to return the object to its base state, and be consumed completely between initialization and recycling. For simplicity, we’ll use JavaScript to showcase a Point recycler object, but these principles apply to other languages as well.

How do it…

Here is a simple data holder object:

function Point(x, y) {
    this.x = x;
    this.y = y;
}

Here is the same data holder object with an initialization and recycler function:

function Point() {
    this.recycle = function() {
        this.x = null;
        this.y = null;
    };
    this.init = function(x, y) {
        this.x = x;
        this.y = y;
    };
}

Create a bunch of Point objects in a tight loop:

for (var i = 1000000; i >= 0; i--) {
    var point = new Point(i, i);
    // do something with point
}

Versus doing the same with the recycler object:

var recyclerPoint = new Point();
for (var i = 1000000; i >= 0; i--) {
    recyclerPoint.init(i, i);
    // do something with recyclerPoint
    recyclerPoint.recycle();
}

See the runtime performance of the Many object test versus the Recycler object test on your device (average of 5 runs on 1M iterations printed to console). On Chrome the JIT does some optimizations to speed up the non-recycler case, so it's not always faster (I was seeing the recycler case consistently faster in Safari and FireFox), but look at the memory timeline if interested in the memory savings (there should be a spike from the non-recycler case and a mostly flat line from the recycler case).

How it works…

While this is a bit of a contrived example, especially since JavaScript engines have so many optimizations for minimizing the cost of object creation/destruction, it does a good job demonstrating what a recycler object looks like. Also, in some browsers (especially older IEs) there will be big performance gains. More importantly memory usage will be more consistent, instead of spikes. This is very useful when not wanting to trigger a GC pause during animations.

For JavaScript, I find this pattern particularly useful, when working with the mousemove event, animation loops, and JSON objects. For a more heavy-weight language like Java, this pattern is useful almost anytime an object needs to be quickly instantiated more than a couple dozen times. And mobile frameworks make heavy use of recycled objects, since memory is often a constraint.

The big gotcha with this pattern is that you cannot store any references to, especially any closures of, the recycler object, as it will most likely be recycled and reused, causing the wrong values to be stored in the outside reference.

There’s more…

The second half of this article is available as Object Pool Pattern in JavaScript.