Trying to design some object pooling

I've done some reading and it seems like using object pooling for creation of many objects is ideal in many ways.

I am trying to design object pooling for creating the different types of projectiles in my game and am having some trouble deciding how to do it.

1. I've never created any kind of pooling before...
2. I'm trying to decide how to design the actual projectile class. Obviously there will be diff types like: Missle, Plasma, Laser etc...

Everything can derive from "AProjectile" which extends my "MovingEntity" class...however something im struggling with is:

Should I create multiple pools for different types of projectiles? (obviously a Missle can't be a Laser) or is there some way I could design an object that can mold to fit any type of projectile thus allowing me to derive all from the base projectile class and therefore have one pool of projectiles...

Also thought I'd see if anyone has some thoughts / examples of how to actually create some object pooling, as I am new to the concept.

Hopefully that all made sense! Love to see what you guys can come up with. Thanks :P

you won't be able to "apply" a type to an already created instance of a different (or ancestor) type.

In terms of pooling implementation, you can quite simply create a desired number of every type you'll be using in your application. You could map Class to a pool of that type in a Dictionary object to constrain your pool access to a single method. Offer another method to return an object you're done with to the pool. The pooling management class can identify the Class dynamically and return it to the appropriate pool.

The chances are that its unlikely that object pooling is really the best solution.

Except in extreme cases, object creation and collection is not going to be a massive performance bottleneck. Object pooling is moderately complex for what you get, and has the risk of the overhead being greater than simply creating objects on demand. Not only that, but the many potential types of objects that need to be pooled sticks a lot of excess complexity in there.

I assume that your goal is performance in using large quantities of objects.
There are alternatives to object pooling that may be more appropriate such as the flyweight pattern (http://en.wikipedia.org/wiki/Flyweight_pattern).

It is far faster to manage creation and deletion of coordinates (Numbers/ints) than complete objects, and opens the possibility for more optimization on top of that (Manually inlining method calls from the flyweight class).

Pools are far more suited to things like threads where creation may take orders of magnitude more time than the calculations being done. The example provided in the flyweight pattern (Characters being displayed in word processors) is really far more appropriate for bullets, there is many of them, they vary only in coordinates, it is impractical to have each one be an object in itself...

Instantiation is a pretty decent bottlenecker... and in the case where you're creating loads of objects like you might with projectiles in a game (or game framework if i remember correctly? where it would give the user an option to pool?) it's certainly worth looking into.

Joa Ebert talks about the huge impact it had on pooling tween objects:
http://blog.je2050.de/2008/05/07/twe...-object-pools/

I would create multiple pools; one for each type of projectile. I don't see that it'd be any slower than making one unified pool, and it makes the thinking a lot easier. Using a unified pool would probably mean that you need to put more code into instantiating each object, I think? I can see that slowing it down. Besides, the way both me and webgeek used when experimenting with pooling was to create one pool per object type. He understands OOP (and coding in general) far better than me, so I'm guessing that if there was any merit in using a single pool, he would've written it that way instead.

If you need any help, I can post my sloppily implemented pooling method. It's actually pretty simple (depending on how your engine's currently set to operate), only maybe 8 lines of code per pool, and can be slipped in and out of the engine pretty tidily. Webgeek has a better implementation (does the same thing in the same way, but with less code on your part - just two function calls per pool, I think), but I never figured out how to use it (although that can be attributed to me being useless at working in OOP).

I wrote this generic pooler real quickly- use should be self explanatory:

PHP Code:

---

package
{
    
    import flash.utils.Dictionary;
    import flash.utils.getDefinitionByName;
    import flash.utils.getQualifiedClassName;
    
    public class PoolingManager
    {
        
        private var _poolMap:Dictionary;
        
        public function PoolingManager()
        {
            _poolMap = new Dictionary();
        }
        
        public function getElementFromPool( type:Class, autoFillAmt:int = 0 ) : Object
        {
            var pool:Array = _poolMap[ type ];
            if( autoFillAmt > 0 )
            {
                if( !pool || !pool.length )
                {
                    createPool( type, autoFillAmt );
                    pool = _poolMap[ type ];
                } 
            }
            return pool.pop();
        }
        
        public function getNumElementsInPool( type:Class ) : int
        {
            var pool:Array = _poolMap[ type ];
            if( pool ) return pool.length;
            return 0;
        }
        
        public function returnElementToPool( element:Object ) : void
        {
            var type:Class = getClass( element );
            var pool:Array = _poolMap[ type ];
            pool.push( element );
        }
        
        public function createPool( type:Class, numMembers:int = 100 ) : void
        {
            
            if( !_poolMap[ type ] ) _poolMap[ type ] = new Array();
            var pool:Array = _poolMap[ type ];
            
            while( --numMembers > -1 )
            {
                pool.push( new type() );
            }
            
        }
        
        public function removePool( type:Class ) : void
        {
            _poolMap[ type ] = null;
        }
        
        private function getClass( instance:Object ) : Class
        {
            var name:String = getQualifiedClassName( instance );
            return Class( getDefinitionByName( name ) );
        }

    }
} 


---

Thanks for the replies. Yea I saw that example from Joa...that was one of the reasons I decided to take that route.

I suppose it would be best to just create multiple pools then...currently my game is structured as follows (the engine anyways) : http:http://www.cheezeworld.com/files/spa...MunsterUML.png

So basically what I could do is have a pool for the same "renderer" object, in which case i'd be using BitmapClipRenderer and all I'd have to do is swap the BitmapClip depending on what "type" of projectile im rendering.

As far as the projectiles I suppose I'll have to create multiple pools for each type of projectile I decide to make...the other solution would to give the "AProjectile" class all the properties than any projectile would need and attach an "actions" class which just has a set of static functions that can be called based on the parameter passed in...( Actions.projectileAction("type", parameters...); )

That would give me a max of 2 pools for the projectiles however it might end up being messy as all of the actions are being stored in one function...and also it would slow things down because I am now calling an extra function withing each projectiles update()...

What do you guys think? Just create multiple pools for multiple types of entities or do the "action" approach?

Maybe it's not apparent, but what I posted handles all the type separate pool creation for you...

it differentiates at the necessary level (Class), which means it only implements logic you'd have to anyway with multiple pool objects. And it keeps everything type safe (which could be painstaking if you need tons of different pools as you'd have to write a different class for each pool type).

lastly, definitely avoid the "action" approach. it breaks a lot of OOP law imo.

Quote:

---

definitely avoid the "action" approach. it breaks a lot of OOP law imo.

---

Yea I agree...it was just a thought I had while writing the reply. NE-ways I looked at your code it looks pretty simple and a good implementation too!

Quote:

---

If you need any help, I can post my sloppily implemented pooling method

---

If you wouldn't mind I'd like to see yours and webgeeks version? Just to get an idea of some different options to try.

Quote:

---

Originally Posted by 691175002

Except in extreme cases, object creation and collection is not going to be a massive performance bottleneck.

---

Try a simple loop test with sufficient iterations, do one test that creates new geom objects (rectangles, points, etc), and do another one that uses object pooling. I think you'll find that object creation with some of Flash's native classes can be a very big bottleneck.

One special case in the originator's game is the lasers. Generally speaking, a laser will be virtually instantaneous from origin to target. Due to this, you can use a simple pooling method that only has to loop from numberDestroyed to numberCreated, rather than having to rearrange a linked list based on destruction. For bullets and missles this won't work due to some objects being destroyed out of the creation order.

Here's a trimmed-down version of one of my Invasion tests, then. Put this script on your main frame (told you it's sloppy):

PHP Code:

---

stage.scaleMode = "noScale";
stage.quality = "LOW";

var infSheetBMP:infSheet = new infSheet();
var troops:Sprite = new Sprite();
var troopPool:Array = new Array();

var frameRate:int=31;
var lowest:int=frameRate;
var checkCounter:int = checkRate = 8;
var startTime = getTimer();
var lowestResetCnt=frameRate*5;
var fps:int = 31;

var tI:int = 0;
var t;

var te:TextField = new TextField();
te.text = "FPS: 31\nTroops: 0";
te.autoSize = TextFieldAutoSize.LEFT;
addChild(te);

function createTroop(tr:Number):void {
    if (troopPool.length>0) {
        myTroop = troops.addChild(troopPool[0]);
        troopPool.splice(0, 1);
    } else {
        var myTroop:Infantry = new Infantry(this);
        var infSprite:Bitmap = new Bitmap(infSheetBMP);
        myTroop.addChild(infSprite);
        troops.addChild(myTroop);
    }
    myTroop.init();
}

stage.addEventListener(Event.ENTER_FRAME, EnterFrame);
function EnterFrame(event:Event):void {
    createTroop();
    
    tI = troops.numChildren;
    while (tI--) {
        t = troops.getChildAt(tI);
        t.eF();
    }
    if(--checkCounter==0) {
        fr = checkRate/((getTimer() - startTime)/1000);
        fps = int(fr*10)/10;
        if (fps<=lowest){
            powest=fps;
        } else {
            if(fps>frameRate){
                fps=frameRate;
            }
        }
        startTime = getTimer();
        checkCounter = checkRate;
    }
    if (--lowestResetCnt==0){
        lowestResetCnt=frameRate;
        lowest=frameRate;
    }
    te.text = "FPS: "+String(fps)+"\nMCs: "+String(troops.numChildren);
} 


---

You'll need to download and put this into your Library:

http://www.birchlabs.co.uk/infSheet.png

And Export it for ActionScript with a Linkage Identifier of infSheet.

Finally, you'll need an Infantry.as in your project folder saying this:

PHP Code:

---

package {
    import flash.display.Sprite;
    import flash.display.Bitmap;
    import flash.display.BitmapData;
    import flash.geom.Rectangle;

    public class Infantry extends Sprite {
        public var _root;
        public var speed:int;
        public var frame:int;
        public var objMode:String;
        public var cond:Boolean;
        public var inc:int;
        
        public var obj:String = "Inf";
        
        public var WIDTH:int = 35;
        public var HEIGHT:int = 54;
        public var FRAMES:int = 17;
        
        public var rect:Rectangle;
        
        public function Infantry(mr:Object) {
            _root = mr;
            cacheAsBitmap = true;
            scrollRect = new Rectangle(0,0, WIDTH, HEIGHT);
            draw();
        }
        public function draw():void {
            rect = scrollRect;
            rect.x = frame * WIDTH;
            scrollRect = rect;
        }
        public function init():void {
            y = Math.floor(245-Math.random()*12)
            x = -50-Math.random()*20;
            frame = 0;
            speed = 3;
            objMode  = "Walk";
            cond = true;
            inc = Math.round(Math.random()*5);
            WIDTH = 35;
            HEIGHT = 54;
            FRAMES = 17;
            scrollRect = new Rectangle(0,0, WIDTH, HEIGHT);
        }
        public function eF():void {
            if (x <= 300) {
                x-=-speed;
            } else if (x>300) {
                x -= 21 ;
                y -= -10;
                objMode = "Die";
                frame = 0;
                FRAMES = 19;
                WIDTH = 54;
                HEIGHT = 44;
                scrollRect = new Rectangle(0, 121, WIDTH, HEIGHT);
            }
            draw();
            frame++;
            if (objMode=="Die") {
                if (frame==FRAMES) {
                    _root.troops.removeChildAt(_root.tI);
                    _root.troopPool.push(this);
                }
            } else {
                if (frame==FRAMES) {
                    frame = 0;
                }
            }
        }
    }
} 


---

Sorry if it doesn't work; I haven't tested that, so I might've removed some unnecessary stuff. I'd compile it all for you, but Flash 9 doesn't run on my Intel Mac. As for webgeek's version... you'd need to ask him for that.

Oh, bear in mind that while object pooling does get rid of the bottleneck of object instantiation, you can still create a far faster entity engine using copyPixels(). My non-pooling copyPixels() engine runs about 20 times faster than this. Comparison:

Pooling sprites (FPS capped at 31, so note that this isn't a very fair benchmark):
http://www.birchlabs.co.uk/Invasion5F9.swf
copyPixels():
http://www.birchlabs.co.uk/Invasion_5.html

V, pooling isn't limited to sprites mate.

I'm sure we've spoken about this before, you can still use bobs with pooling rather than just sprites.

Squize.

I know it's not limited to sprites. But if the engine can handle 7,000 bobs (or 2,000 with collision detection) fine without pooling, you don't really need to go to the extra length of pooling it. The bobs in my copyPixels() engine only have the properties x,y,frame,HP and objMode, so object instantiation isn't a pressing overhead.

Nevertheless, I'm going to try pooling my copyPixels() engine in a few weeks, once my GCSEs have finished, and see if it makes any significant difference.

My point is simply that even for something like lasers, as Vengeance said, you can drop a bit of the OOP fluff and make something both fast and simple.

A copyPixels engine is really quite similar to a flyweight pattern as you have a single object representing many with data being swapped in through arrays.

While object instantiation compared with reuse or pools in a simple for loop will show major performance gains, toss in a reasonably sized copyPixels or draw operation in the loop and the difference suddenly becomes much smaller. Considering each object may draw itself 30+ times during its lifetime I feel the following test is far more telling:

Code:

---

Results of test:
Constant Reinstantiation: 551
Reuse: 537

---

Code:

---

var bd:BitmapData = new BitmapData(800,600);
var cpy:BitmapData = new BitmapData(200,200);
bd.lock();

var p:Point = new Point (0,0);
var r:Rectangle = new Rectangle (0,0,40,40);


var n:Number = getTimer();
var pp:Point;
var rr:Rectangle;
for (var i:int = 0; i < 10000; i++) {
        // A basic bullet symbolized by a point and rectangle
        pp = new Point();
        rr = new Rectangle();
        for (var j:int = 0; j < 30; j++) {
                bd.copyPixels(cpy,r,p);
        }
}
trace ("Constant Reinstantiation: " + (getTimer() - n));

n = getTimer();
for (i = 0; i < 10000; i++) {
        // A basic bullet symbolized by a point and rectangle
        pp.x = 0;
        pp.y = 0;
        rr.x = 0;
        rr.y = 0;
        rr.width = 0;
        rr.height = 0;
        for (j = 0; j < 30; j++) {
                bd.copyPixels(cpy,r,p);
        }
}
trace ("Reuse: " + (getTimer() - n));

---

You will notice that even when two completely new objects are being created each iteration, there is less than a 3% speed difference as soon as you throw in some realistic operations. This isn't even being compared to a pool, just reusing the same two objects.


I generally try to design out situations that involve hundreds or thousands of objects cycling each frame to begin with. The cases where an object pool is truly necessary (And better than the many alternatives) are far between.

Thank you, 691175002. :) Was hoping for some evidence along those lines. Webgeek said (if I recall correctly) that object pooling is only necessary when you're instantiating big objects that inherit loads of methods and properties, which is why the Sprite example benefits from it (inherits DisplayObject, which is massive). Point() and Rectangle() don't seem to be too intensive, but they still have a not insignificant number of properties and methods in them. A typical bob object might have even less overhead than one of these.

I'd be interested in seeing the speed difference between a Point being created, and a Sprite.

Here is the same test, changed to sprites:

Code:

---

Constant Reinstantiation: 636
Reuse: 549

---

A little more of a difference, but considering how heavy a sprite is, on top of the fact that a sprite will probably live longer than 30 frames, make me still think that there are better alternatives.

As well, on this scale a pool with both a hashtable lookup as well as a push/pop will have overhead.

I think there are a couple of problems with your test for reinstantiation, but I could be thinking about it the wrong way, so please correct me if I'm wrong here.

The rectangle and point objects used in your copy pixel call are not the ones created. This may not make a difference, but should be fixed.

PHP Code:

---

            bd.copyPixels(cpy,r,p);

// should be

        bd.copyPixels(cpy,rr,pp); 


---

The second issue is that you are in fact using object pooling in both tests, due to the fact that you reuse the same rectangle and point objects in the second loop of each test. This should be done in the reuse test, but not in the reinstantiation test if you want results with no pooling. Perhaps remove the second loop and instead use more objects. That or:

PHP Code:

---

for (var i:int = 0; i < 10000; i++) {
    // A basic bullet symbolized by a point and rectangle
    for (var j:int = 0; j < 30; j++) {
        pp = new Point();
        rr = new Rectangle();
        bd.copyPixels(cpy,rr,pp);
    }
}
trace ("Constant Reinstantiation: " + (getTimer() - n));

n = getTimer();
for (i = 0; i < 10000; i++) {
    // A basic bullet symbolized by a point and rectangle
    for (j = 0; j < 30; j++) {
        pp.x = 0;
        pp.y = 0;
        rr.x = 0;
        rr.y = 0;
        rr.width = 0;
        rr.height = 0;
        bd.copyPixels(cpy,rr,pp);
    }
}
trace ("Reuse: " + (getTimer() - n)); 


---

Either way, the results of your tests show reuse (pooling) to be faster, so why argue against it?

You misunderstand what is being tested.

The first test works like follows:
I assume that someone is creating a set of lightweight object, keeping each one for thirty frames (Each frame performing a single copypixel operation) then discarding it.
In the inner loop, the point and rectangle are kept the same, because it is assumed that each instance will have its own point and rectangle for personal use (Or an external class which handles drawing will also be reusing the same Point/Rect). The drawing is irrelevant to the test, I am simply padding the loop with plausible operations to show that in real life, perhaps 1% of execution will be spent creating new objects in comparison to what the objects are doing, even with something so short lived.

The second test is essentially the same, except that we are reusing instead of creating new Rectangles and Points.


Now, keep in mind that this is a test between Reuse and complete reinstantiation. Not a test between a pool and a flyweight. This just demonstrates that the most optimal solution, not creating or storing any new objects is less than 3% faster than the slowest possible solution with lightweight objects.

Now, if you wanted to simulate a pool you could toss in a hashtable lookup and a push/pop in an external class in each iteration, on several arrays of hundreds of entries in length. The gap starts to close.
I am quite confident that when you are using lightweight objects such as bullets, there will be no practical performance gain to a pool, and potentially a performance loss if your class is lightweight.


I still stand by my statement that in almost all cases, pools are either unnecessary or solve a problem that could have been avoided in the first place, even more so for something like bullets.

Thank you for all of the data, I really appreciate it. I think perhaps just creation objects won't be so bad but I'll still use a factory for it all just in case later I can swap in some type of pooling on the backside and have it all still work fine.

I do actually create a few things each time a projectile is created so pooling would probably give some sort of gains on situations with large amounts of things flying around...however from your tests I suppose I can just focus on that later if I really feel it is even a cause of concern for performance.

I was just trying to juice as much performance out of all the small stuff as I could to make as much room for the AI / Collision once I get to that.

Overall good discussion so far though methinks! :P

Thanks for the explanation. I first used pooling with heavy object usage with good results, so I have always used it since, without taking into regard a lightweight case. One of those traps you fall into from good results.

Good tests and good posts 002.

I can't help but still feel pooling is more than worth the effort. In a real world example where you'd use pooling ( Let's say a game with a lot of bullets and particles ) you may not get the maximum benefit straight away, but after a certain point the game will max out in complexity ( ie number of objects needed ) so no more will need to be created, they'll just be pop'ped out of an array and give their init data to start them off.

Sticking with it being more real world, let's take a bullet as an example. At it's most basic it needs an image to plot ( Either a sprite or bitmap data to blit, let's stick with blitting ), some coords to say where it starts, speed / direction, a reference to the playfield bitmap to blit it to and methods to update it's position, dispose of it, possibly have collision checks in there etc.

With doing it as a complete reinstantiation object you'd pass the init details to the constructor and that would then set everything up.

With pooling, you'd have the constructor which would just have one shot info passed to it, such as a reference to the playfield and then a seperate init method to give it it's speed / direction / start point etc.
But in the constructor you'd be able to set up any speed up constants you may need, eg shorter references to Math.sin, Math.cos, PI etc. Anything that only needs setting once ( Even to the point of creating the copyPixel plotting point, eg pos=new Point() and any rectangle objects that are needed, then in the init method you can just set the individual properties of these ).

With this approach, it would take in effect two method calls ( The constructor when you first create an instance, and the init() method ) with data being passed to both, but like I said above the game will soon have enough objects not to need any more, so it will only be the init method being called with less data being passed to it to set things up.

Again, only relatively small savings, but it all adds up, and in terms of code it's really next to nothing to add.

Squize.

Hmmm yea you are probably right Squize...now that I think about it I do actually instantiate a lot more than just a simple "projectile" object.

I actually create two classes. The projectile which extends "MovingEntity"..and inside that I create several "Vector" classes as well as several references etc etc...

Then I create a "BitmapClipRenderer" which uses my BitmapClip class and sets up some bitmap and bitmapData objects to render that to the main screen...so all in all quite a few things are being created just for a projectile...

If I did pooling all id be doing is sending like a "params" object which like you said data about the target, speed, etc... and then the bitmapclip to "copy" which wouldn't create a new bitmapclap but rather it would just swap its array reference to the input bitmapdata array...(whatever)

Anyways with the number of projectiles and particles I am creating like this it probably would make a bit of a difference actually.

I messed around with pooling while implementing doom-a-like, because I was creating a lot of data structures that were built, used and discarded all in the same frame. They were POD types for describing spans of pixels in a bitmap, very much flyweights. I was never impressed with pooling.

I didn't take down any numbers to back it up, but pooling did not seem to have any impact on the time spent on instantiation. The only reason I would take a stab at it again, was (i) if I really wanted to avoid invoking the GC on such a regular basis, or (ii) was working with a very strict memory footprint (mobile device?). None of the games I have made since do any pooling, they just gobble the heap and exploit the GC as god intended. [Commandment #11 ;) ]. I haven't looked back, and at this point I don't think the architectural adjustments (however minor they may be) are worth the effort.

Quake-a-like has data structures with similar single-frame lifetimes, uses no pooling, and outperforms doom-a-like by lightyears. I know it's comparing apples and oranges because they work so differently under the hood, but my opinion is that pooling will never be an optimization that has a measureable impact on your final frame rate, unless your example is contrived to do so.

I tried to think of a good way to make a pooling class that was strongly typed / templated like the C++ STL but never came up with it. I like newblacks solution, so maybe it's worth giving another shot if I ever find myself in a situation (i) or (ii).

Pooling isn't always the best solution, but for certain things ( Such as a lot of on-screen objects like in a shoot'em up ) I think it's better to do it than not.

Squize.

AGHH!! so much conflicting advice! lol

It seems to remain true that pooling is faster, even if only slightly. With the GC being a possible factor in any object or bitmap heavy game, pooling has advantages.

Unless someone posts an example that shows pooling to be slower, I still don't see a valid argument against it.

Well I have been meaning to do some performance testing flash for a while now, and this seems to be the time.

As far as I see it, there are three major variations that can be tested here:

• Naive - Creating new instances
• Pooling - Reusing the same set of instances
• Modified Flyweight - Feeding in primitive data

This time I will use something more substantial as a test. I will be using my IsoTest which extends IsoSprite.

I believe this is a pretty generic representation of a common game object, it has a set of coordinates, draws itself and has an update function among others.

It is by no means a heavyweight, but it is far larger than a point/rectangle.

The code for these two classes follows:

Code:

---

package Display {
        import flash.display.BitmapData;
        import flash.geom.Point;
       
        /**
        * Base class for the update/render architecture.
        * IsoSprite contains the isometric coordinates for all drawn objects.
        *
        * Depending on desired behavior, you may simply extend this class and
        * add instances of it to the DefaultController, or create your own
        * controller/factory system.
        *
        * @author Ryan Turner
        */
        public class IsoSprite {
                //==========================
                // Coordinates =============
                //==========================
                // Coordinates
                public var x:Number;
                public var y:Number;
                public var z:Number;
               
                // Inalidation marks the sprite for removal
                public var valid:Boolean;
               
                // Marks the sprite as having its position changed
                // Will not be depth sorted if false
                public var sort:Boolean;
               
                //==========================================
                // Constructor =============================
                //==========================================
                /**
                * Creates an isosprite
                * @param        _x
                * @param        _y
                * @param        _z
                */
                public function IsoSprite(_x:Number, _y:Number, _z:Number) {
                        x = _x;
                        y = _y;
                        z = _z;
                        valid = true;
                        sort = false;
                }
               
                //==========================================
                // Override ================================
                //==========================================
                /**
                * Draw this sprite at point p on bitmap data bd.
                * @param        p
                * @param        bd
                */
                public function draw (p:Point, bd:BitmapData):void {
                       
                }
               
                /**
                * Update the sprite
                * @param        t Time, in ms since the last frame
                */
                public function update (t:Number):void {

                }
               
                /**
                * Clean up any assets used by the sprite
                */
                public function dispose ():void {
                        valid = false;
                }
               
                //==========================================
                // Compare =================================
                //==========================================
                /**
                * Negative 1 if it a should be infront of b.
                * @param        a
                * @param        b
                * @return
                */
                public static function comp (a:IsoSprite, b:IsoSprite):Number {
                        if (a.x > b.x)
                                return 1;
                        if (a.x < b.x)
                                return -1;
                        if (a.y > b.y)
                                return 1;
                        if (a.y < b.y)
                                return -1;
                        if (a.z > b.z)
                                return 1;
                        if (a.z < b.z)
                                return -1;
                        return 0;
                }
        }
}
package Display.Sprite {
        import Display.IsoSprite;
        import flash.display.BitmapData;
        import flash.geom.Rectangle;
        import flash.geom.Point;
       
        public class IsoTest extends IsoSprite {
               
                private var sheet:BitmapData;
                private var r:Rectangle;
               
                public function IsoTest (_x:Number, _y:Number, _z:Number, _sheet:BitmapData, _rectangle:Rectangle) {
                        super (_x, _y, _z);
                        sheet = _sheet;
                        r = _rectangle;
                }
               
                public override function draw(p:Point , bd:BitmapData):void {
                        bd.copyPixels(sheet, r, p);
                }
        }
}

---

The basic premise of the test will be similar:
We want an efficient method of drawing short lived sprites that contain simple behavior. In detail:

• Object life will be 20-60 frames
• Objects keep track of position
• Objects draw themselves
• Objects have an update function

There is not much to be said about the first test, where new instances are created each time. It will form the baseline as the worst possible method.

The object pool test will be harder to simulate in a for loop as there will be only one instance in use at a time. I do not believe this will impact performance in any way though, as long as I fill the pool with ~400 objects to begin with.
I will be simulating newblacks sample code, which performs a hashtable lookup and a push/pop for each element. Another faster alternative would be a circular array however I don't feel like coding one at the moment and the difference should be negligible.

The flyweight pattern will involve a single class that represents every IsoSprite. Essentially, make every member of IsoSprite an array, and loop through these primitives. The code should make it clear.

Tests:
I don't feel like doing all three in a single file, so first:

Creating new instances
Quite straightforward, 50,000 iterations of creating an IsoTest, drawing it x number of times and then repeating.

Code:

Code:

---

import Display.Sprite.IsoTest;

var display:BitmapData = new BitmapData(800,600);
var copy:BitmapData = new BitmapData(400,400);

var area:Rectangle = new Rectangle (0,0,40,40);
var p:Point = new Point (0,0);

var it:IsoTest;

var n:Number = getTimer();

for (var i:int = 0; i < 50000; i++) {
        // Instantiate a new IsoTest
        it = new IsoTest(0,0,0,copy,area);
       
        // Perform 20/60 draws (Varies by test)
        for (var j:int = 0; j < 60; j++) {
                it.draw(p,display);
        }
}

trace (getTimer() - n);

---

Results:
Lifespan of 20 frames: 1970ms
Lifespan of 60 frames: 5816ms
Pretty straightforward, tripling the lifespan increases the time almost linearly.

Object Pool
I dont route my method calls through another object, I manually simulate an object pool in the for loop. I don't think this will cause any major difference.

Changes from the previous test is that initially (And before the timer starts), I populate an array with 400 objects. From there, instead of instantiating i perform a hashtable lookup, pop off an element, reset its members and push it back on at the end.

Code:

Code:

---

import Display.Sprite.IsoTest;

var display:BitmapData = new BitmapData(800,600);
var copy:BitmapData = new BitmapData(400,400);

var area:Rectangle = new Rectangle (0,0,40,40);
var p:Point = new Point (0,0);

var it:IsoTest;

var aPool:Array = new Array();
var dict:Dictionary = new Dictionary();
for (var k:int = 0; k < 400; k++) {
        aPool.push (new IsoTest(0,0,0,copy,area));
}

var n:Number = getTimer();

for (var i:int = 0; i < 50000; i++) {
        // Hashtable
        dict[IsoTest];
        // Pool
        it = aPool.pop();
        it.x = 0;
        it.y = 0;
        it.z = 0;
        // Note that I do not reset its bitmapData or drawing area
       
        // Perform 20/60 draws (Varies by test)
        for (var j:int = 0; j < 60; j++) {
                it.draw(p,display);
        }
        // Stick it back on
        aPool.push(it);
}

trace (getTimer() - n);

---

Results:
Lifespan of 20 frames: 1940ms
Lifespan of 60 frames: 5781ms
Very small differences, approximately 30ms was saved in both tests.

Modified Flyweight
This is probably the least "OOPish" design. I don't find it that big of an issue though since it is very encapsulated and hidden behind an object. Like with the pool, I didn't feel it necessary to create a complete implementation, only simulate what is being done.

Of particular interest is that a flyweight is essentially three seperate pools, but as these pools only act on numbers they are still faster than a single pool of objects.

Code:

---

import Display.Sprite.IsoTest;

var display:BitmapData = new BitmapData(800,600);
var copy:BitmapData = new BitmapData(400,400);

var area:Rectangle = new Rectangle (0,0,40,40);
var p:Point = new Point (0,0);


// Arrays of primitives
var ax:Array = new Array();
var ay:Array = new Array();
var az:Array = new Array();

// Fill em up, to 400 like with the pool
for (var k:int = 0; k < 400; k++) {
        ax.push (0);
        ay.push (0);
        az.push (0);
}

// Note that a flyweight is basically a pool but with primitives except objects.

var n:Number = getTimer();

for (var i:int = 0; i < 50000; i++) {
        ax.push (0);
        ay.push (0);
        az.push (0);
       
        // Perform 20/60 draws (Varies by test)
        for (var j:int = 0; j < 60; j++) {
                display.copyPixels(copy,area,p);
        }
       
        ax.pop();
        ay.pop();
        az.pop();
}

trace (getTimer() - n);

---

Results:
Lifespan of 20 frames: 1838ms
Lifespan of 60 frames: 5450ms
This provides approximately a 130ms gain over 20 frames, and a 360ms gain over 60 frames. Well over 4 times the speed increase gained by a pool.
I might as well mention why there is this gain. In a 60 frame life object, you have 1 call to the constructor, but 120 calls to the update/render methods. A flyweight inlines these calls into a loop. Sure, you have a few more arrays, but you also remove the overhead of 120 method calls.

Also, I forgot to call the update(); method in these tests. Since its empty it wouldn't really change much and I didn't feel like redoing all the tests. Calling update() would have increased the speed gain of a flyweight by a moderate amount as well (Aka handicapping all other tests with 50,000*60 method calls).

Conclusion
While yes, a pool will gain you, optimistically 3% speed (And this test showed only 1.5%), frankly, thats not worth it and a flyweight will provide closer to 7%.

What I really want to make the most clear here is that performance on this scale might as well not exist. There is a reason big O notation will drop performance gains of hundreds of percents. It does not matter. In the grand scheme of things, this entire section of your engine may take 3% of your processing time, rendering even a 10% gain completely worthless.
Things like switching from an exponential algorithm to a logarithmic one will help, squeaking fractions of a percent out by complicating your architecture wont.

Note that using an object pool will increase your framerate from 30fps to 30.0135fps. (Assuming that 3% of execution time is spent dealing with instantiation, a heavy guess).

What this test does show is something that should make a lot of sense: One call to the constructor is nothing compared to the hundred of method calls that an object will receive over its life. If you want speed, inline those functions. Don't bother optimizing something that is only called once when there is something else getting 120 calls right beside it.

Don't get me wrong, there are places for pools, but lightweight objects aren't one of them.

The only thing I will mention is garbage collection. Object pools and flyweights both have the advantage of not creating tonnes of orphaned objects. I have not experienced it myself, but orphaning hundreds of objects a frame may cause excessive use of the garbage collector.

Whew...