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:
Cant view source...
ReplyDeleteIf 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).
ReplyDeletehttp://www.arcanearcade.com/Flex/SpeedTest/index.html
have played a lot around with alchemy to somehow speed up BitmapData-access, but the native way seems to be the best right now.
ReplyDeleteso 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!
Kris: regarding amf, dont you leave out the (de)serialization of those flash types takes some time - which could be called marshaling again?
ReplyDeleteYes 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.
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.
ReplyDeletei 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
@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.
ReplyDeleteFor 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