AS3 is FAST! Redux - CopyPixels vs. Sprite Pooling

[tonypa]

I was planning to do some test about it myself. Just so I understand what method you are using, let me see if the basics are correct:

1. Sprite Pooling.
*You have separate sprite object for each arrow.
*Bitmap from memory is loaded into each arrow bitmapdata object.
*Arrows are added to stage using addChild.
*Arrows are moved by updating their x and y properties.
*Scrollrect property is changed for each arrow at every step.

2. Copy Pixels
*1 general arrowsprites bitmapdata object is created.
*You have general object for each arrow (not the sprite object).
*Arrow sprites are not added to stage.
*At the stage is visible just 1 big bitmap object.
*Arrows are moved by updating their x and y variables.
*Main bitmap is cleared at each step.
*CopyPixels is used to copy image from arrowsprites object to main bitmap into position of each arrow.

Is the description correct so far?

[VENGEANCE MX]

Something that's being overlooked in both these tests, though, is memory.

Using OS X's Activity Monitor, I watched Safari running both examples (500 frames, 50 arrows per frame). For object pooling, the real memory stayed firm at about 88 MB and the virtual memory went to about 400 MB.

But with copyPixel, the real memory went from about 160-400 MB (kept incrementing steadily then dropped down again; probably the garbage collector) and the virtual memory reached 600 MB.

There's something I'd like to point out... I think of it as the 'spike', and I think it's caused by the garbage collector clearing up. It happens in the copyPixels example, and the object pooling example when pooling is disabled. Every few seconds, the movie freezes for about half a second (and I think it's at this point that the copyPixel goes from using 400 MB back to 160 MB of RAM). You don't get this with pooling, because objects aren't being removed. The memory usage stays constant, so you don't get freezes every few seconds. If you haven't noticed this (I'll be honest, I had to pay close attention to notice it in the copyPixel test), try using 500 arrows in the object pooling test, with pooling disabled. Much more noticeable there.

Also, am I noticing that the copyPixel example doesn't seem to have an alpha channel? The arrows don't fade out, and there's no anti-aliasing. I'd trade the 3 fps speed difference I get for the graphical improvement object pooling allows.

So, round-up...

Sprite Pooling:
Consistently low memory usage
Alpha channel
Significantly faster enterFrame execution
About 3 fps slower
No memory spike

CopyPixels:
Erratic memory usage
No alpha channel
Slow enterFrame
3 fps speed boost
Memory spike

Maybe this is just me not having the will to do another rewrite of Invasion 5, but I still prefer object pooling. The average user can't be expected to use as much as 400 MB of RAM for a Flash game (although this is in extreme cases; realistically you wouldn't use so many sprites under any circumstances - performance results across computers would be too inconsistent), and they won't appreciate the lack of an alpha channel. Plus, believe it or not, some people don't seem to notice a 3 fps speed difference. :s

And Tonypa, that all seems correct to me, but you've left out the whole point of the sprite pooling method - the pool. When objects would usually be removed, they are instead moved into an array to be re-used when the next object is created.