[AS3] Performance in lange loop

[Verwijderd]

Het viel me onlangs op dat de volgende iteratie (pseudo) veel geheugen gebruikt:

code:

// voorbeeld A
for(var i:int = 0; i < 10000; i++) {
    for(var y:int = 0; y < 10000; y++) {
        doSomethingEasy((5000 + 3400) / 2);
    }
}

Ook deze oplossing gebruikt (evenveel) geheugen:

code:

// voorbeeld B
var berekening:Number = (5000 + 3400) / 2;
for(var i:int = 0; i < 10000; i++) {
    for(var y:int = 0; y < 10000; y++) {
        doSomethingEasy(berekening);
    }
}

Terwijl dit vele malen minder geheugen gebruikt (door de berekening te vervangen door de uitkomst):

code:

// voorbeeld C
var berekening:Number = 4200; // = (5000 + 3400) / 2;
for(var i:int = 0; i < 10000; i++) {
    for(var y:int = 0; y < 10000; y++) {
        doSomethingEasy(berekening);
    }
}

De waarden 5000 en 3400 zijn variabel, echter wijzigen binnen de iteratie niet. Ik heb het idee dat in voorbeeld B de calculatie "berekening" 10000*10000 maal uitgevoerd wordt (en daardoor geheugen vreet), ondanks het feit dat ik het in een variabele stop van te voren.

Kan iemand me in het kort uitleggen hoe ik dit proces kan optimaliseren, en de waarden 5000 en 3400 dynamisch (dat wil zeggen: dynamisch voordat de iteratie begint) kan houden? Ik snap niet goed hoe actionscript dit afhandelt; daaarbij geloof ik graag dat dit niet alleen voor AS maar ook voor andere talen geldt.

Bedankt.

PS Het probleem zit hem niet in doSomethingEasy. Wat daar gebeurt is irrelevant; het probleem focust zich op de berekening van "berekening".

[ Voor 4% gewijzigd door Verwijderd op 06-10-2011 12:49 . Reden: Uitleg over doSomethingEasy gegeven. ]

[Jegorex]

Ik heb zelf nooit met AS3 gewerkt, maar is het mogelijk om "berekening" final te maken?
Heb je al gekeken wat er gebeurt als je de loop in een aparte methode zet en "berekening" als parameter meegeeft?

[alienfruit]

Tja, de berekening wordt nu dus gewoon 10000² uitgevoerd er zijn immers twee for-loops. Je zou je int kunnen veranderen in een uint. Verder het cachen van je `berekening` variabele is een goed idee. Normaal gesproken helpt een `const` niet maar je kan het proberen. Tja, als die waarde toch niet vaak veranderd dan zou ik het gewoon doen zoals het niet is.

Verder interessant lees voer: http://jacksondunstan.com/articles/tag/performance

[ Voor 37% gewijzigd door alienfruit op 06-10-2011 14:34 ]

[G70boX]

Maakt het gebruik van een uint t.o.v. een int in die for loop echt iets uit? Ik kan het hier helaas zelf nu niet testen, maar het lijkt me dat dat niet veel uit zou moeten maken?

Of bedoelde je de berekening variable?

[Verwijderd]

alienfruit schreef op donderdag 06 oktober 2011 @ 14:32:
Tja, de berekening wordt nu dus gewoon 10000² uitgevoerd er zijn immers twee for-loops. Je zou je int kunnen veranderen in een uint. Verder het cachen van je `berekening` variabele is een goed idee. Normaal gesproken helpt een `const` niet maar je kan het proberen. Tja, als die waarde toch niet vaak veranderd dan zou ik het gewoon doen zoals het niet is.

Verder interessant lees voer: http://jacksondunstan.com/articles/tag/performance

Ik begrijp niet goed dat de berekening 10000² uitgevoerd wordt (zou het niet eenmaal moeten zijn?). Ik voer die berekening immers voor de iteratie uit (en stop het in de variable). Het lijkt echter inderdaad 10000² te zijn.
Dit leert me dat als je de uitkomst van een berekening in een variabele stopt, de berekening alsnog daadwerkelijk uitgevoerd wordt, iedere keer dat je de variable gebruikt.

Caching is inderdaad wat ik nodig heb, maar het lukt me niet om dat te realiseren (declareren met const werkt niet). Gebruik maken van een uint maakt ook geen verschil.

Ik kan me niet voorstellen dat ik de eerste ben met dit probleem.
*start zoektocht naar oplossing nogmaals*

[liquid_ice]

Waarschijnlijk heeft de automatische inlining nu een ongewenst effect.
voor C++ bestaan er (afhankelijk van de compiler) noinline opties.

Maar ik ken AS3 niet, sorry

[RobIII]

Ik durf met enige zekerheid te stellen dat er meer aan de hand is danwel dat de meetmethode niet erg betrouwbaar is of verkeerd uitgevoerd. De symptomen die TS beschrijft zijn niet bepaald logisch.

[SaphuA]

Ik kan haast niet geloven dat voorbeeld 2 en 3 veel verschillen.
AS3 is crap, maar zal toch niet zo erg ongeoptimaliseerd zijn?

[Jegorex]

SaphuA schreef op vrijdag 07 oktober 2011 @ 16:11:
Ik kan haast niet geloven dat voorbeeld 2 en 3 veel verschillen.
AS3 is crap, maar zal toch niet zo erg ongeoptimaliseerd zijn?

Het voordat van niet optimaliseren is dat een float veel nauwkeuriger zal blijven als je er later nog meer berekeningen mee gaat uitvoeren denk ik.
Maar in dit geval is het wel ongewenst en onnodig.
(Number is altijd een integer?)

[Matis]

@TS, het zal geen geheugen vreten, hoogstens processor-load.

Daarnaast weet ik niet of AS3 de berekening (als variabele) of de berekening als echte berekening by reference meegeeft (met andere woorden, de variabele berekening verwijst naar de fysieke berekening en zal dus telkens worden uitgevoerd) of naar de uitkomst van de berekening.
Ik weet ook niet hoe de promotion/degration van de berekening zich verhoudt tot de variabele Number.

[Wolfos]

10k*10k is honderd miljoen.
Honderd miljoen keer iets doen duurt nou eenmaal lang.

[Tsjilp]

Kan me niet voorstellen dat B & C veel verschil maken, zou in ieder geval niet moeten.
Kan je ook laten zien wat er in de functie staat die je aanroept?

Kijk voor AS3 optimalisaties trouwens ook eens hier: http://wiki.joa-ebert.com...ategory:Code_Optimization

[Jeldert]

Het zou niet kunnen dat er veel verschil zou zitten tussen A, B en C. Er is namelijk niks aanwezig dat meer geheugen zou gebruiken in A en B, maar niet in C.

Toch maar even alle 3 getest, en geheugengebruik is bij alle 3 identiek. Ook het verschil in tijd die het kost voordat de berekening klaar is, is verwaarloosbaar in deze 3 voorbeelden.

Als je daadwerkelijk verschil in geheugengebruik ziet, ben ik toch benieuwd naar je meetmethode, en wat doSomethingEasy doet. Let wel: het is met Flash erg lastig om precies dezelfde performance-gegevens te krijgen bij meerdere runs.