AS3: Notes on Non-Alchemy Fast Memory Access

To be honest, my recent project has been getting more and more boring. The core stuff is basically done, and almost everything left is grunt work — nothing new or fun. Yesterday I finished The Settlers 7, was just about to drift off to sleep, and then suddenly came across two pages that perked me right up: [http://www.buraks.com/azoth/](http://www.buraks.com/azoth/) and [http://philippe.elsass.me/2010/05/as3-fast-memory-access-without-alchemy/](http://philippe.elsass.me/2010/05/as3-fast-memory-access-without-alchemy/) . Suddenly I was wide awake. When it comes to handling certain crazy requirements, the speed of reading from and writing to a ByteArray in FlashPlayer just can't keep up. These past couple of days [Xu Can](http://www.asblog.org/) got pushed into having to hunt for some heretical, unofficial hack — and he actually found one. I'd heard before that haXe is so efficient because its author found the low-level interface FlashPlayer 10 provides for Alchemy, but for various reasons I never went and used haXe. Seeing these two pages showed me yet another trick — turns out they're all wares from the same circle. All three of them found the “back door” FlashPlayer 10 opened for Alchemy in order to boost performance at a low level.

Flash

Loader's resources are not released

Yesterday I ran into a memory leak. After digging all the way down, I found it was caused by the bitmap captured for the reflection in an external .swf that had been loaded not being cleared. My guess is that although loader.unloadAndStop() closes the stream, it doesn’t release the BitmapData created inside the loaded program. Keep this in mind: aside from purely media-playback objects, if the external program you load has listeners, callbacks, or has created BitmapData, then that external program needs to clean up after itself before it’s unloaded. Otherwise, no matter how much you gc, it’ll still be eating memory.

Flash