I’m fascinated by Adobe’s Alchemy project, which compiles C and C++ code into ActionScript, and stayed up late last night to give it a try. I used Ubuntu Linux, which felt brave since the instructions are for Windows (using Cygwin, which enables somewhat Unix-like development) or Mac.

Techie note: It took me a while to get going; like a number of others I ran into a configuration problem, the symptom being that you type alc-on, which is meant to enable the special Alchemy version of GCC (the standard open source C compiler), but instead get “Command not found”. In the end I ran the command:

source $ALCHEMY_HOME/alchemy-setup

directly from the terminal instead of in my bash profile, and that fixed it. The command alc-on is actually an alias created by this setup script.

After that it was relatively plain sailing. I used a recent version of the Flex 3 SDK, and adapted the stringecho.c example to create a countprimes function, because I was curious to see how it would compare to other results.

The result of my efforts was a Flex library called primetest.swc. I copied this to my Windows box, where I have Flex Builder installed. I configured Flex Builder to use Flash Player 10 and the Flex 3.2 SDK. Then I modified the prime-counting applet so I could compare the Alchemy version of the function with ActionScript. Once you have the .swc, the Alchemy code is easy to use:

import cmodule.primetest.CLibInit;

//code omitted

if (chkAlchemy.selected)
{
    var loader:CLibInit = new CLibInit;
    var lib:Object = loader.init();
    numprimes = lib.countprimes(n);
}
else
{
    numprimes = countprimes_as(n);
}

Then I tried the application. Note this is not using the debug player.

As you can see, the Alchemy code is slightly slower than ActionScript. I also tried this with a higher value (10,000,000) and got 34.95 secs for Alchemy versus 32.59 secs for ActionScript.

Conclusions? First, despite the slower performance, Alchemy is mighty impressive. Let’s not forget the intent of Alchemy to enable reuse of C and C++ libraries; it is not just about speed.

Second, note that Alchemy is still a research project and may get faster. Further, I may have missed some tricks in my code.

Third, note that this sort of tight loop is ideal for just-in-time compilation and really should run at speeds close to that of native code anyway. In Silverlight or Java it does.

So does the test prove anything? Well, it shows that Alchemy won’t always speed your code, which raises the question: in what circumstances will it be a performance win? There is a useful post here from Joe Steele:

The potential wins on performance are if you are operating on a large ByteArray (because of the optimized ByteArray opcodes) or if your code is doing a lot of boxing/unboxing (which largely goes away with Alchemys arg passing model). You are ultimately getting ActionScript out so if you already have hand-tuned ActionScript that avoids boxing/unboxing and is dealing with small chunks of data, you are not likely to beat that with Alchemy.

My experience is in line with his comments.

The general claim made in this thread (see Brandan Hall’s post) is that:

… under favorable conditions [Alchemy] runs 10 times slower than native code but 10 times faster than ActionScript

I guess the big question, from a performance perspective, is how much real-world code that is worth optimizing (because it does intensive processing that the user notices) falls into the “favorable conditions” category. If that turns out to be not many, we may have to abandon the idea of Alchemy as a performance fix, and just enjoy the portability it enables.