Can AS3 and Alchemy be friends?

Ok, so many of us tried to use Alchemy opcodes in AS3 projects, years ago. But how many keep using it every day ever after? Not me. Why? Well, where do we start…

What is it good for?

Adobe introduced these opcodes to implement memory access operations required by LLVM, so that Alchemy could do its thing, and Flash Player could run C++ code. But for AS3 people these opcodes did not do anything magical. It was just another way to read numbers from or write to one ByteArray at a time that, coincidentally, worked faster than IDataInput/IDataOutput. So, if you were to do some number crunching, it might save you some milliseconds.

The problem I have with this is that now, when ASNext is abandoned and AS3 performance is being surpassed by JavaScript, many people tend to bring up these opcodes as valid solution to *all* our “make AS3 faster” pleas. Just how exactly fast numeric array IO is supposed to help with complex data types known as classes? Good question.

Placing your class fields in domain memory

In C++ you have pointers, but in AS3 you don’t, so placing your class data there will be ugly. But, if you will be able to access them normally (via dot syntax) and faster at the same time, why not try it? So I did: using legacy compiler and azoth, I did this simple test, and… got domain memory based loop running over 50 times slower than plain AS3. WTF?? Turns out domain memory is only fast if you set your ByteArray to use LITTLE_ENDIAN order (it’s the opposite by default). With LITTLE_ENDIAN memory opcodes were about 10 times faster, but this was still not enough to bridge the gap caused by having to use getters and setters now instead of plain variable fields.

Enter the ASC2

ASC2 has two features that make it interesting in this case. First, it can inline method calls. Second, it can emit memory opcodes without 3rd party tools. So, after people reported that this was indeed working for my cause, I opened my FB 4.7 trial and went on to try that myself. I was confused a lot by the fact that none of memory opcodes were present in playerglobal.swc, but it turns out you can ignore that – the code will compile and run any way. This time everything went better than expected – I had domain memory based loop finally running 30 to 50% times faster, although timings fluctuated a lot update: I bumped arrays length to get better numbers on desktop; for MBP/Chrome/11.6 they were on average 220 ms vs 110 ms, for Windows/standalone/11.6 – 250 ms vs 190 ms. Finally, for iPad3/ipa-test/AIR 3.7 they were 200 ms vs 275 ms (memory opcodes loop was slower).


People on twitter were fast to remind me that apparat had similar feature for quite some time. This way is probably the best way to use memory opcodes for people who cannot use ASC2. I wanted to include apparat-based test for this post, too, but it turns out I don’t have it installed here (nor do I have scala). It’s not that hard to install but, as lazy as I am, this is not something I am willing to do for the sake of this blog post. So you are going to have to trust in that it works, because clever people made it.


7 Responses to “Can AS3 and Alchemy be friends?”

  1. 1 Jackson Dunstan April 11, 2013 at 03:41

    Alchemy (now FlasCC) is best used as a way to get existing C/C++ libraries to work in Flash/AIR. The “Alchemy opcodes”, as you point out, can be used in a variety of ways: ASC 2.0, Apparat, HaXe, Azoth, etc. Then you can link the two together via the AS3-C/C++ bindings in FlasCC. It’s actually pretty flexible but, again as you point out, not something that most people will use on a day-to-day basis. Still, it can be really fast at some tasks.

  2. 2 katopz (@katopz) April 11, 2013 at 05:35

    what’s it look like on mobile?

  3. 4 biscuit June 11, 2013 at 05:09

    Um, I can’t import “avm2.intrinsics.memory.sf64” too as you mentioned. How did you use the opcodes?

  4. 6 biscuit June 17, 2013 at 11:34


  1. 1 An ASC 2.0 Domain Memory Opcodes Primer « Trackback on July 22, 2013 at 11:01

Ask a Question

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Old stuff

April 2013
« Mar   May »

Oh, btw…


%d bloggers like this: