Feedback: lime.utils.ObjectPool<T>


Hey guys,

Yesterday I struck out to create a simple API for creating an ObjectPool. There aren’t good examples that I can find of popular APIs people use already, so I would really appreciate help and feedback to discover how you guys would want to have an ObjectPool work.

In Flixel, an FlxGroup can add() and remove() objects, and getFirstAvailable() for objects that are added, but unused.

I like the idea of being able to easily add and remove objects, but I fear this doesn’t work well if someone wants to have the ObjectPool allocate for them, or have a set size.

I currently have this API, but again, feedback is welcome

var pool = new ObjectPool<Sprite> (function () return new Sprite (), 20);
trace (pool.size); // 20
var sprite1 = pool.get ();
var sprite2 = pool.get ();
pool.release (sprite1);
var sprite3 = pool.create ();

The size argument is optional. An ObjectPool with no size will allow growth. The get() method will return null if the size number of objects is already used. create() will always return an object, even if it exceeds the number of objects for the pool.

One downside is that when you get() an object, it’s flagged for use and counts toward the size. If you lose your reference to the object, it remains in the pool forever.

If we were to not use a size, we could have get() return an object, and the pool could not retain a reference. If you get() and forget to release(), at least it would be garbage collected, though you might miss that you are causing extra GC activity this way.

Please help me know if you think we should change this (before it is released in Lime), if both create() and get() is good, name preferences, etc, etc

Thank you :grinning:


Can the object pool be made out of any kinds of objects, like some .swf files for instance ?
Asking this because have been getting some problems with hitting ram size issues with some not so big .swf files that bloat up in memory, crashing flash.


Yep, it should work for (conceivably) any type of object, so long as you can return the object to the pool and don’t have to rely on garbage collection


It’s about animations played repeatedly at certain points of a match so I wouldn’t need to count on gc.
I don’t know if it is even possible to generate a 64 bit exe, that would certainly fix it with higher memory limits. Some swf files go from 2 MB to using upwards of one GB when playing and it blows flash out, will try if this runs for c++ compile.


We do 32-bit Windows builds for simpler backward compatibility, but 64-bit Windows builds are planned. I think you can do it now in the tools, but we don’t distribute 64-bit builds ourselves