1. Optimization and tooling FCNY July 2010

3.  AS3 is only a tool  Apparat and TDSI  Wireworld code remap example  Adding your Tools to a Build Process  Q & A  Kumbaya

4.  Many languages can script SWFs AS3, MXML, AS2, HaXe, C, C++, Lua …  Different reasons to use each one AS3: common Alchemized C: runs fast, but hard to write HaXe: runs fast, targets practically everything  (Tramp.)

5.  Did you know? Alchemy C code can run at 30% the speed of native C code AS3? 3%  Use the tools at your disposal  Pick the right tools for the right job You can use more than one at a time, you know

6.  Behind Audiotool Joa Ebert  TAAS – bytecode analyzer, optimizer  Stripper – removes SWF debug data  Reducer – compresses PNGs in SWFs  Concrete – lets you implement abstract classes  Coverage – unit testing thingy  TDSI

7.  It's a car modding term. We're not supposed to get it.  Finds slow "dummy code" in your SWF that you deliberately placed in your AS3  Replaces them with Alchemy opcodes  Fast Math replacement  Memory system  Inlining and macros ?

8.  We’ll start with a slow AS3 app and improve it in stages.  Generally applicable strategies for optimization

9.  Particle system… but stuck in a grid  Information leaks from pixel to pixel  Instead of  particle.move(); particle.drop();  It’s  pixel.countNeighbors(); pixel.changeColor();  Supports circuit-like systems  WW computer by Owen and Moore (Quinapalus.com)  wireworldAS3 (Google Projects)  I get a lot of attention from Germans…?

11. DISCLAIMER  wireworldAS3 is needlessly complicated.  Show and tell  This complexity isn’t required from your own projects.  the Apparat project contains some example code that may be easier to follow at home

12. Naïve implementation for ( every row ) { for ( every column ) { there is a pixel. for ( every neighbor of the pixel ) { do something. } update the pixel's state. } }

13. Naïve implementation  Result: sucks  Slow, slow, slow, slow.  Touching every pixel seems dumb

14. New idea  List the pixels (or nodes) that might change their neighbors for ( each node in the list) { for ( each neighbor of the node) { if ( the neighbor might change its neighbors next time ) { add it to a new list } update the node } } Then swap the old list with the new list.  Way less work

15.  Arrays  untyped (slow)  ordered (unnecessary)  weird  push() and pop() are expensive and lame

16.  Linked lists are easy: every node points to the next node in the list  start  node  node  node  node  null  Chop it and you get two LLs  Connect their ends and they’re one again  No pushing or popping  No class  Result: better

17.  Grab that second beer.  Optimization is never an end unto itself It’s so easy to forget that Performance matters in four or five situations: 1Addressing bad user experience, freezing process 2Facing stiff competition 3Porting code to mobile devices 4 plotting world domination  Otherwise, don’t we all have enough on our plates already?

18.  How about filters? Pixel Bender?  Wireworld rule is basically a weird BitmapFilter  These work, but they're slow  Remapping to these is scary  Some tasks can be PBJ'd, but not all of them  Result: disappointing

19. Property Vectors instead of objects  Make a Vector for each node property  xVec, yVec, stateVec  node.next.x becomes xVec[ nextVec[ i ] ]  Replaces the node class with ints, Booleans and other Vectors  The Vectors don't grow or shrink, but the data changes its value  Nodes now point to each other with an index  The linked lists are still in there

20. Property Vectors instead of objects  Wait! We can't use null.  You have to make a custom null. Call it something else. Nada. Diddly. Buggerall. Squat. Bupkis.  It’s just an int, like -1, that we use to signify nothingness.  Doesn’t work well with dynamic properties  There are ways around this  Maybe you shouldn’t be using dynamic properties  Result: on par with linked lists  Main advantage: all the data is primitive.

21. ByteArray time  We can pack our primitive data into a BA  Write out the values of each property for each cell, same order every time.  Result:  SUCKS!

22. Wait. What??

24.  Use TDSI’s Memory API  Slows your program way down at first  (Don’t freak out)  Run the SWF through TDSI  Result: Excellent

25.  Cut a big loop into a repeatable task  Perform the task in response to a timed event  Stop the task when the loop test fails  Overdrive  Packing the flash event loop  Framerate threshold  Don’t forget to solve the problem

26.  Wireworld won’t impact most people.  Other systems can seriously benefit Audio players/synths Emulators Graphics engines Solvers Tough stough

27.  Consider: This is probably the most efficient SWF we've ever compiled during a talk at FCNY  Hard task  Runs fast  Targeting mobile devices Your app will stand a better chance (Apparently WW already runs nice on Froyo)

28.  Bash script / Bat file Write it just once Tack it on the end of your FB builders list Register it as an external build tool  Most IDEs offer some way of doing this Double click it  Ant build for Eclipse fans  AGAIN: implementation before optimization BAT BASH

29.  Please direct all your questions to Hudson. Thank you.