AS3 Flash Efficient Code Techniques, Vectors in Flash 10, Faster JPEG Encoding, Other Optimization Notes

Flash 10 will be ready for mainstream hopefully by the end of this year, or early ’10 when the penetration numbers will be up in or around the 90% range via zeh fernando based on previous trajectories.  

With that, Flash 10 has many great new things such as the Vector structure that allows a collection of a certain type, which results in a faster collection because of the known type.  So anywhere where Arrays are used, that is a possible candidate for a performance increase within some code because you are asking the virtual machine to do less work on each loop (not having to dynamically find out the type).

ByteArray (Thibault Imbert) has demonstrated that for the JPEG encoding in corelib it is up to 2.5 times faster using Vectors than Arrays.  Your mileage may vary heavily but it is almost a guaranteed speed boost due to less work.  This obviously has great possibilities for speeding up code that uses lots of arrays.  

Due to the performance boost the Vector does have some constraints in the typical give and take of coder flexibility with compiler and virtual machine overhead.  Vectors are more explicit and strongly typed which is why they are fast, but this is also limiting.

In addition to the data type restriction, the Vector class has other restrictions that distinguish it from the Array class:

  • A Vector is a dense array. Unlike an Array, which may have values in indices 0 and 7 even if there are no values in positions 1 through 6, a Vector must have a value (or null) in each index.
  • A Vector can optionally be fixed-length, meaning the number of elements it contains can’t change.
  • Access to a Vector’s elements is bounds-checked. You can never read a value from an index greater than the final element (length - 1). You can never set a value with an index more than one beyond the current final index (in other words, you can only set a value at an existing index or at index [length]).

 [ Vector docs  ]

ByteArray not only used Vectors heavily but did other optimizations that are always good to do, even though optimization is evil when you are working with precious client side resources ensuring an optimized base starting point can be a good thing.

So what did I do ?

  • I used bitwise operators as much as possible.
  • I replaced all Arrays with fixed length Vectors.
  • I used pre-incrementation rather than post-incrementation (thanks Joa for this one ;)).
  • I casted to int all my Vector indices access.
  • Other minor stuff you always do to optimize your code 

Other sources as well for even more optimization or shall I say efficient AS3:

Tags: , , , , , , ,

  • Pingback: AS3 Optimization and F10 « The Algorithmist

  • TK

    The Vector is a nice addition to Flash 10, but it can’t really be used to its full potential. Since type generics aren’t supported in Flash Player yet, all Vectors have to be hard-coded, so it’s pretty much useless in work with frameworks. If Flash Player were able to support type generics (parameterized types), I’m sure we’d see a lot more people using it. Then, rather than using ArrayCollections in Flex, we’d be able to use VectorCollection for huge performance gains as noted.

    Here’s hoping we get generics in the next version of Flash Player….

  • Robin Debreuil

    “optimization is evil”

    This is a common thing you hear, but imo that is utter bs. Obfuscation is evil, but optimization is a good thing. Obviously in some situations one leads to another, but most of the time not. Performance always matters, nowhere more so than on the flash player.

  • Macaca

    Good stuff. Next up: graphics optimisations.

  • maliboo

    I hope that FLARToolkit will get Vector-optimized version…

  • drawk

    @TK – totally agree. They aren’t as impressive as generics in other languages yet but it is getting there. Even though AS3 is more strongly typed it is still a dynamic language which isn’t all bad but can slow things down.

    @Robin – True, optimization can be evil (such if you are optimization to one version of a compiler that can change and kill your app performance in a version). But in most cases starting with an efficient base is not really evil optimization at all. Not many tricks there. I think the optimization is evil thing was from the past a bit in that hardware was really expensive and coders would take advantage of a compiler switch or some quirk that sped things up but later causes issues when that optimization maybe failed. Compiling in essence is optimization so not all optimization is evil, just the kind that might only be beneficial for the life of a glitch.

  • k0zer

    Gavrilin, Derevokas, Cederash, Ferinannnd – spam.

  • bart

    check it out: . There’s some code about that :)

  • drawk

    bart, very nice, Alchemy always wins :)

  • Pingback: Flash and the art of optimization « whitenoise

  • Pingback: 7 interessante sommerartikler · omFlash();

  • Pingback: » ActionScript 3.0程式最佳化(二)