Sweating the Small Stuff - PowerPoint Presentation

Slide1

Sweating the Small Stuff

Optimization and tooling

FCNY July 2010Slide2

MachinariumSlide3

Here's what this talk is about

AS3 is

only a toolApparat and TDSIWireworld code remap exampleAdding your Tools to a Build ProcessQ & AKumbayaSlide4

AS3 ≠ Flash

Many languages can script

SWFsAS3, MXML, AS2, HaXe, C, C++, Lua …Different reasons to use each oneAS3: commonAlchemized C: runs fast, but hard to writeHaXe: runs fast, targets practically everything(Tramp.

)Slide5

AS3 ≠ Flash

Did you know?Alchemy C code can run at 30% the speed of native C code

AS3? 3%Use the tools at your disposalPick the right tools for the right jobYou can use more than one at a time, you knowSlide6

Apparat

Behind Audiotool

Joa EbertTAAS – bytecode analyzer, optimizerStripper – removes SWF debug dataReducer – compresses PNGs in SWFsConcrete – lets you implement abstract classesCoverage – unit testing thingyTDSISlide7

TDSI

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 AS3Replaces them with Alchemy opcodesFast Math replacementMemory systemInlining and macros?Slide8

So

here’s what we’re going to do

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

Wireworld

in a nutshell

Particle system… but stuck in a gridInformation leaks from pixel to pixelInstead ofparticle.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…?Slide10

Wireworld

in a nutshellSlide11

DISCLAIMER

wireworldAS3

is needlessly complicated.Show and tellThis complexity isn’t required from your own projects.

the

Apparat

project contains some example code that may be easier to follow at homeSlide12

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. }}Slide13

Naïve implementation

Result: sucks

Slow, slow, slow, slow.Touching every pixel seems dumbSlide14

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 workSlide15

Linked

List

instead of ArrayArraysuntyped

(slow

)

ordered

(unnecessary

)

weird

push

() and

pop

() are

expensive and lameSlide16

Linked

List

instead of ArrayLinked 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: betterSlide17

Let’s take a breather

Grab that second beer.

Optimization is never an end unto itselfIt’s so easy to forget thatPerformance matters in four or five situations:Addressing bad user experience, freezing processFacing stiff competitionPorting code to mobile devices

plotting world domination

Otherwise, don’t we all have enough on our plates already?Slide18

Are there any other bright ideas?

How

about filters? Pixel Bender?Wireworld rule is basically a weird BitmapFilterThese work, but they're slow

Remapping to these is scary

Some tasks can be

PBJ'd

, but not all of them

Result: disappointingSlide19

Property Vectors instead of objects

Make a Vector for each

node propertyxVec, yVec, stateVecnode.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 thereSlide20

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.Slide21

ByteArray

time

We can pack our primitive data into a BAWrite out the values of each property for each cell, same order every time.Result:SUCKS!Slide22

Wait. What??Slide23

Wait. What??

BAs +

[your project] = SUPAH FAST!!!1 Dopes.

BAs aren’t a cure-all.

ByteArray.position

Like a needle on a record player or hard disk

It’s fast, as long as you don’t

lift that needle

BAs in AS3 will perform well for you in many cases, just not all cases

TDSI manipulates

BAs with Alchemy

opcodes

, not the BA methodsSlide24

Finally, the TDSI step

Use

TDSI’s Memory APISlows your program way down at first(Don’t freak out)Run the SWF through TDSIResult: ExcellentSlide25

Bonus: green threads

Cut a big loop into a repeatable task

Perform the task in response to a timed eventStop the task when the loop test failsOverdrivePacking the flash event loopFramerate thresholdDon’t forget to solve the problemSlide26

Was all that really

worth it?

Wireworld won’t impact most people.Other systems can seriously benefitAudio players/synthsEmulatorsGraphics enginesSolversTough stoughSlide27

Was all that really worth it?

Consider:

This is probably the most efficient SWF we've ever compiled during a talk at FCNYHard taskRuns fastTargeting mobile devicesYour app will stand a better chance(Apparently WW already runs nice on Froyo)Slide28

Fitting

tools like TDSI

into your workflowBash script / Bat fileWrite it just onceTack it on the end of your FB builders listRegister it as an external build toolMost IDEs offer some way of doing thisDouble click it

Ant

build for Eclipse fans

AGAIN:

implementation

before

optimization

BAT

BASHSlide29

That’s it.

Please direct all your questions to Hudson. Thank you.