Friday, March 13, 2009

Alchemy Data Manipulation Faster Than Vectors

While working with Alchemy to port a roguelike library to handle field of view calculations for a 2d tile game (The Doryen Library, port is called libtcod-alchemy) I noticed some drastic speed differences between using a ByteArray in pure AS and manipulating that same ByteArray inside Alchemy. Out of curiosity I wondered how Alchemy manipulations of large data structures would compare to a native AS Array or the new (and faster) Vector.

As it turns out, Alchemy wins hands down when the data is already in a ByteArray. If you need to transfer data from an array/vector into a ByteArray to hand off to Alchemy and then transfer it back, it is slower to use Alchemy. For this test I have a collection of 1,000,000 numbers and for each iteration of the test, I loop over the numbers and add one.

Alchemy ByteArray additions are about 6 times faster than Vector integer additions and 10 times faster than pure AS manipulations of a ByteArray (when using Array notation [] on a ByteArray to manipulate a Byte - using position, readInt() and writeInt() in AS is much slower).

Below is test program that proves it:

Note that the demo above requires Flash Player 10 (required by Alchemy).

NOTE: If you want view the source, you need to go here and right click on the app (the embedded version in blogger doesn't know where to look for the source).

This tells me a few things:
  • There is a great deal of room for improvement in ActionScript's compiler since it should perform better IMHO. I understand some slow downs due to type safety, garbage collection, etc but I didn't expect the huge difference.
  • If Alchemy had native access to the same Native calls used to seralize data to AMF that is used in AS (described here), Alchemy would be blazingly fast for manipulating data even when stored in Arrays or Vectors. You would just serialize the objects as AMF into Alchemy, manipulate the data with Alchemy, and serialize it back out as AMF back to AS.
  • The ByteArray.position is much slower than I would expect.
  • If you need to process large amounts of data, seriously consider using Alchemy. Remember the marshalling tax to and from Alchemy - every bit of data passing into and out of Alchemy takes time to marshall, so you want to do it in large chunks like in my speed test.
You may notice that the first Alchemy test takes more time than normal - this is due to initialization of the Alchemy library.

In case you are curious essentially the same test takes:
  • GCC C Code - 1 or 2 milliseconds
  • GCC Lua Code - 300-400 milliseconds
  • Lua Alchemy - 8 seconds (might be including some of the time to get the tick count from ActionScript)

6 comments:

  1. Cant view source...

    ReplyDelete
  2. If you want to view source, you need to go to the web page serving the app rather than the one embedded in blogger (which doesn't know where to find the source).
    http://www.arcanearcade.com/Flex/SpeedTest/index.html

    ReplyDelete
  3. have played a lot around with alchemy to somehow speed up BitmapData-access, but the native way seems to be the best right now.

    so im glad you found out theres really an advantage at some point ;)

    i still believe its very hard to find scenarios in which alchemy makes sense. ralph hauwert showed a nice and amazingly fast way of plotting 3d particles on fitc amsterdam. unfortunately hes not the source sharing type of guy, but i guess the whole thing is written in alchemy to avoid any kind of marshaling.

    regarding amf, dont you leave out the (de)serialization of those flash types takes some time - which could be called marshaling again?
    maybe about the same amount of time it takes to writeObject() an Array to ByteArray..? havent tested that yet, but i miss this in the argumentation.

    nice flexy way to show the differences though (: research away!

    ReplyDelete
  4. Kris: regarding amf, dont you leave out the (de)serialization of those flash types takes some time - which could be called marshaling again?
    Yes that would be some marshalling but... AMF is serialized on Flash using native C code to create an array of bytes - so it is very fast. My tests show that byte array manipulation is faster in Alchemy. The tests have performance problems because I manually change an array or vector into a byte array. If I could write AFM from Flash and had a C AMF library in Alchemy I'm sure I could approach the speed gains I saw manipulating ByteArrays.

    I could probably write a simple AMF read/write in Alchemy that just handles an Array or Vector of ints to test this.

    ReplyDelete
  5. if you want the serialization on the alchemy side it has to have knowledge about the flash-objects to use.. which again would mean crossing the flash/alchemy border.
    i guess ive missed something :)

    because - as i understand it - to writeObject() a serializable object to a ByteArray is exactly what id expect to happen; regardless of whether its initially written in alchemy or AS, the only thing which may be faster was the function call itself - not the time to process the serialization.

    -- ok, had a look into your sources now!
    maybe we can talk little more in-depth via mail? kris @ the url my name is linked to

    ReplyDelete
  6. @kris I think you're being unfair to Ralph now. He is indeed a "source sharing type of guy", but (as everybody else) he can't share all his code for various reasons. I usually do, but there's many reasons not to share code. If it's too messy and I don't have time to clean it, if it's partially owned by a client or has bugs - I won't release it.

    For this experiment Ralph has certainly published the source: http://www.unitzeroone.com/blog/2009/03/18/flash-10-massive-amounts-of-3d-particles-with-alchemy-source-included/

    J

    ReplyDelete