[Flash] ActionScript benchmarks

[GrimaceODespair]

Naar aanleiding van onder andere dit en de bij mij constant rijzende vraag wat nou de snelste constructies zijn in ActionScript, heb ik even een pagina aangemaakt met wat benchmarks. Ik weet niet of er ergens anders al een soortgelijk project bestaat, maar indien niet, dan ga'k er mss es wat extra moeite insteken.

Eerst even uitleg over hoe ik het heb aangepakt. Ik voer 1000x een stukje testcode uit dat ik time: dat is 1 run. Ik heb per stukje code dat ik wilde testen een overzicht gemaakt van 100 runs en geef per run ook aan hoeveel de gemiddelde run duurt over een venster van 10 runs (dus stel dat je run n bekijkt, dan zie je in de eerste kolom n staan, in de tweede de tijd die de run in beslag nam, en in de derde de gemiddelde tijde over runs n-10 t/m n).

De stukjes testcode die ik tot nu toe heb uitgevoerd zijn, staan in onderstaand stukje script (natuurlijk wel afzonderlijk gebenched), waarbij eerst de gebenchte code, daarna het gewogen gemiddelde over 100 runs, en tenslotte een omschrijving van de bench:

Flash ActionScript:

v = "v";      //  74.74 ms, code 1: zonder declaratie van v
var v = "v";  //  66.96 ms, code 2: inline declaratie
v = "v";      //  74.13 ms, code 3: met declaratie van v (vooraf)
v.text = "v"; //  95.84 ms, code 4: met initialisatie van v als Object in AS
v.text = "v"; // 195.12 ms, code 5: met initialisatie van v als TextBox on scene
v = "v";      //  77.25 ms, code 6: met v gebonden aan een TextBox

Hoe ik het benchen in ActionScript zelf heb gedaan, zie je bovenaan de pagina.

Ik trek uit de timings alvast de volgende conclusies:

• Het gebruik van een inline declaratie gaat snel. Blijkbaar kijkt de AS-engine in dit geval enkel de lokale scope of zo. Het is iig het tegenovergesteld als wat in bv C++ gebeurt, waar afaik declaraties in een loop de boel vertragen.
• Het zetten van een variabele die aan een textbox gelinkt is, vertoont slechts een zeer lichte overhead (en ik twijfel zelfs hier aan, of het niet gewoon aan mijn wsch statistisch onverantwoorde aanpak ligt).
• Het zetten van een var in een object geeft een overhead tov rechtstreeks een var zetten, wsch doordat de AS engine nu 2 vars moet opzoeken (het object + zijn var).
• Een TextBox doet behoorlijk wat werk achter de schermen als je zijn text zet en verdubbelt de overhead tov het gewoon zetten van een object variabele.

Waar ik nou nog benieuwd naar ben, het verschil tussen

code:

x.i

en

code:

x["i"]

Zodra ik er meer over weet, zet ik't hier neer.

Tenslotte nog een opmerking over de machinerie waar ik de boel op bench. 't Gaat om een goeie ouwe PII 400, niet fancy, dus de timings zijn niet erg snel.

[Verwijderd]

Leuk, goed gedaan.

Wat betreft die scoping: inderdaad, zonder var word er eerst buiten de scope van het object gekeken.....of op _levelnr gezet. Daat moet je mee uitkijken.

Wat betreft dat verschil tussen x.i en x[i], da's nogal voorspelbaar.....x[i] zal in een loop elke keer opnieuw evalueren.

var temp x[i];
en dan loopen is dan vooral de oplossing.

Wat eventueel interresant is is om te kijken in hoeverre het 'gewicht' van een variable er toe doet. Ook het 'gewicht' van een variable naam is interresant.

Wat ik in je bench ook zie is dat je v.text = "v" doet, terwijl dit binnen een loop dan ook elke keer geevalueerd word. Interresanter is op nieuw om dat ding in een var te knallen....

Sorry....veel drank gehad gisteren.

[oh,when?]

GrimaceODespair schreef op 07 februari 2003 @ 11:20:Waar ik nou nog benieuwd naar ben, het verschil tussen

code:

x.i

en

code:

x["i"]

Zodra ik er meer over weet, zet ik't hier neer.

leuke info..thnx!

iig voor bovenstaande, heb het nog even uitgetest in bytecode, en de assignment en retrievement van zowel dot als array notatie maakt niets uit, ze genereren dezelfde bytecode. theoretisch zou het dan even snel moeten zijn.

HTH

[GrimaceODespair]

oh,when? schreef op 07 February 2003 @ 13:27:
iig voor bovenstaande, heb het nog even uitgetest in bytecode, en de assignment en retrievement van zowel dot als array notatie maakt niets uit, ze genereren dezelfde bytecode. theoretisch zou het dan even snel moeten zijn.

'k Heb zelf eigenlijk nog nooit de bytecodes proberen uit te vogelen. Het zal wel luiheid zijn, maar welke tool gebruik jij daar voor?

Het kan overigens wel es 2 tot 3 dagen duren voordat ik de volgende benchmarks plaats, want tis een beetje druk nu. Daar komt nog bij, bedacht ik mij ineens, dat deze benchmarks gemaakt zijn met een bepaalde process-configuratie in mijn OS-geheugen. Dat wil dus zeggen, dat als ik volgende keer mijn PC opstart, de Flash anders zal reageren, en de andere benchmarks dus deprecated zijn. Dus zal ik alle runs nog es opnieuw moeten doen... zucht... iemand een idee hoe ik dit best kan aanpakken? Want ik vertrouw er niet zo op dat Windows dezelfde benches geeft na elke opstart (dat zou ik op zich natuurlijk ook nog kunnen benchen )

[Verwijderd]

GrimaceODespair schreef op 07 februari 2003 @ 13:50:
[...]

'k Heb zelf eigenlijk nog nooit de bytecodes proberen uit te vogelen. Het zal wel luiheid zijn, maar welke tool gebruik jij daar voor?

flasm

[oh,when?]

en een linkje omdat ralph weer eens te lui is.. :P

[Verwijderd]

oh,when? schreef op 07 February 2003 @ 14:44:
en een linkje omdat ralph weer eens te lui is.. :P

B-Top is een eikel.

[oh,when?]

Flash ActionScript:

frame 0
  push 1000
   label1:
    decrement
    dup
    dup
    push 'Je bent een eikel'
    trace
    branchIfTrue label1
   pop
 end
end

[Guillome]

oh,when? schreef op 07 February 2003 @ 20:25:

Flash ActionScript:

frame 0
  push 1000
   label1:
    decrement
    dup
    dup
    push 'Je bent een eikel'
    trace
    branchIfTrue label1
   pop
 end
end

Hmm dat kan ik niet invoeren.
Of moet dat op een speciale manier in de editor?

[oh,when?]

XLerator schreef op 07 februari 2003 @ 21:17:
[...]

Hmm dat kan ik niet invoeren.
Of moet dat op een speciale manier in de editor?

dat is nu flash bytecode....zie paar posts hierboven voor de compiler/decompiler...

[GrimaceODespair]

Ok, ik heb de lethargie doorbroken en dan ook maar es naar Flasm gekeken. Het lijkt mij nu zelfs interessanter te kijken naar wat voor bytecodes de bovenstaande code oplevert, dan naar de timings, omdat uiteraard de bytecodes meer bepalend zijn dan de oorspronkelijke code.

Waarom ik nu ineens deze ommezwaai maak? Het lijkt verdomd moeilijk om die benchmarks in absolute waarden bij te houden. De prestaties van Flash filmpjes zijn zeer load-gevoelig, dwz dat bv een gemiddelde van 70 ms door WinAmp kan opgetrokken worden tot 80 ms. Laat ik dus maar zwijgen van het verschil tussen Windows sessies. Dus alle gemeten absolute waarden zijn misschien niet volstrekt nutteloos, maar toch hoogstens bruikbaar voor relatieve vergelijkingen van de op dat moment gebenchte stukken code.

Precies door die load-gevoeligheid, is ook nog eens AS-code die op zich niet gebencht wordt (dus de variabelendeclaraties, de onEnterFrame code, ...), toch van invloed op de gebenchte code, omdat ze de load van de Flashplayer beïnvloeden. Dus als we benchcode gebruiken, moet liefst alle code, behalve de gebenchte, hetzelfde zijn.

Toch is er een lichtpuntje in de tunnel. Ik heb mijn vorige bench es herhaald met lichtjes gewijzige benchcode (een optelling + if-statement toegevoegd om automatisch het gemiddelde over alle runs te berekenen) en daarna hetzelfde nog eens met WinAmp aan (spam: check out de excellente jazzy chill muziek op flaresound.com). De onderstaande tabel toont de resultaten. De procenten zijn de afwijkingen tov de eerste kolom.

#	Nieuw	Origineel	WinAmp
1	76.78	74.74 (97%)	92.50 (120%)
2	69.17	66.96 (96%)	84.51 (122%)
3	77.34	74.13 (95%)	92.56 (119%)
4	96.54	95.84 (99%)	114.56 (118%)
5	219.83	195.12 (88%)	261.07 (118%)
6	77.39	77.25 (99%)	93.06 (120%)

De relatieve afwijkingen lijken dus enigszins stabiel te zijn, op de uitschuiver van 5 na. Een relatieve bench zou dus mogelijk moeten zijn, waarbij er 1 bench als ijkpunt geldt. Dwz, als je gaat benchen moet je altijd ook die ijkbench runnen. Ik denk dat er wel nuttige bevindingen mee te scoren vallen, ook al lijkt er af en toe een flinke deviatie te zitten in opeenvolgende runs en zelfs sets van runs (100 x 1000 x dezelfde code uitvoeren levert blijkbaar nog altijd geen solide gemiddelde).

Dit alles in beschouwing nemende, lijkt het mij. zoals ik reeds in het begin van mijn epistel aangaf, zeker nuttig om ook eens te kijken naar wat de resulterende Flasm code is voor de gebenchte instructies. Dit levert het volgende op:

#	AS	Bytecode
1	v = "x"	constants 'v' push 'v', 'v' setVariable
2	var v = "v"	constants 'v' push 'v', 'v' varEquals
3	var v v = "v"	constants 'v' push 'v' var push 'v', 'v' setVariable
4	var v = {} v.text = "v"	constants 'v', 'text' push 'v', 0.0 initObject varEquals push 'v' getVariable push 'text', 'v' setMember
5	// v is een TextBox v.text = "v"	constants 'v', 'text' push 'v' getVariable push 'text', 'v' setMember
6	// v is gebonden aan een TextBox v = "v"	zie 1

Dit maakt iig al duidelijker wat er achter de schermen allemaal gebeurt. Terwijl ik dit zo in elkaar zat te draaien en de Flasm-pagina steeds verder had doorgenomen, werd mij ook duidelijker dat mijn benchmarks niet verschrikkelijk relevant zijn. Veel nuttiger is het om te kijken naar

1. wat voor bytecode de AS oplevert
2. wat de snelheid van die bytecode is

En, hoewel er mss hier en daar nog wat werk aan is, worden deze dingen eigenlijk al vrij uitgebreid besproken door de maker van Flasm en de mailing lists van FigLeaf. Daarom heb ik besloten maar eens op zoek te gaan naar extra informatie over de Flash bytecode instructies en hun snelheid (die figleaf mailing list is high traffic ). Misschien kom ik er wel achter dat ik de bytecode instructies moet gaan benchen, maar het lijkt er toch op dat die Flasm-pagina al het leeuwendeel aan onderzoek heeft verricht.