Other than the really obvious bit that its direct access to a block of ram/fast memory which works extremely quickly, there is one other small but vital detail that's haXe specific and makes a vast difference between alchemy and haxe.

The Big Difference

You can think of flash.Memory as a static ByteArray, thus it is accessible from both static class and instance methods.

Now, another feature which offers huge speed increases in haXe is inlining.

Spelling it out - You can only inline static private methods, flash.Memory is all static access. So stick all your data (or big chunks of it) in flash.Memory and then inline  most of your heavy number crunching class.

All inlined, all using fast memory = very very quick swfs!

Ideas and Tricks

First of all, get the thought of only being able to have one chunk or type of data in fast memory at a time, you can partition it up and load everything in there.

A common setup I use is to have the first 1024 bytes as fast storage for float, int, byte, uint variables, the next xxx-thousand bytes as raw bitmap data, then all the other data I may want - like a block of 500k x,y,z floats for 3d data, followed by a few lookup charts.

the first 1024 bytes as fast storage for float, int, byte, uint variables - because you can then access the most commonly used vars using small int offsets (0-255) - and since its a small int your using it avoids all stacks completely, the bytecode will only contain the opcode to get the value from fast memory followed by the offset actually in the bytecode - for anything 256 and over its going to hit the int stack to get the offset first (which is barely noticable, but you know every fraction counts)

the next xxx-thousand bytes as raw bitmap data - because you can then work on your bitmap data ultra fast and write it back to the BitmapData instance using setPixels; very fast indeed, faster than a fixed sized vector even.

then all the other data - this is partially obvious, what may not be is the use of lookup charts, but I'll cover that in a moment.

Accessing..

Remember flash.Memory differs from a byte array in that you have to add in the offset for each value you want to grab

• Byte = 1 Byte
• Int = 4 Bytes
• Float = 4 Bytes
• Double = 8 Bytes

To use flash.Memory with functions which require a ByteArray.. [ like BitmapData.getPixels() -  Sound.extract() ] .. you can access it directly from flash.system.ApplicationDomain.currentDomain.domainMemory for example:

// set position to start of the data we need
flash.system.ApplicationDomain.currentDomain.domainMemory.position = SOME_OFFSET;
// use the fast memory
bitmapData.setPixels( bitmapData.rect , flash.system.ApplicationDomain.currentDomain.domainMemory );

note: don't be fooled though, you can't simply call the functions on the bytearray in currentDomain, although it is the data that is in fast memory, it does not use the opcodes, which are what speed it up!

Lookup Charts

Often you'll find yourself calling the same code over and over and over; perhaps without realising just how much; consider we make an animation which uses perlin noise to generate 2d or 3d data - like this example - the example reads about 40k uint values from perlin noise, then converts each pixel to individual r,g,b values, then turns it in to a float -1 to 1 using a simple calculation. Thing is.. that means the same calculation runs 3x40000 times per frame at 50 frames a second.. 6 million times a second!

In this scenario, there are only 256 possible inputs to the calculation and 256 results - so rather than working it out 6 million times we can load it all in to a lookup chart, stick the lookup chart in fast memory and then lookup values rather than calculating - often you can really speed things up by doing this. Practical example with comments here.

Hope this is of use to somebody and clears things up a bit; I use the methods often so you'll see them in the source of my experiments.