Trying to design some object pooling

[JerryScript]

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.

[Squize]

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.

[ColbyCheeze]

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.

[rachil0]

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).

[Squize]

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.

[ColbyCheeze]

AGHH!! so much conflicting advice! lol