[Java] Code-optimalisatie / GC ontlasten

[MichielPH]

Beetje uit daadwerkelijke optimalisatie, beetje uit interesse, vroeg ik me af hoe de Java compiler omgaat met dit stukje code:

Java:

    private void setForce(float screenX, float screenY) {
        mTemp.set(screenX, screenY);
        mTemp.sub(mX, mY);
        mTemp.rotateRad(-mAngle);
        
        float balance = 2 * mTemp.y / mHeight;
        
        mForce.set(0, Constans.BALANCER_MAX_FORCE).scl(balance);
    }

mTemp en mForce zijn 2 vectoren. Het gaat me om de variabele balance, het enige nut dat dit een gedeclareerde variabele is, is voor mijn eigen overzicht. Als onderdeel van een game zou het kunnen dat dit 30 - 60 keer per seconde uitgevoerd gaat worden.

Is de compiler zo slim dat dit uiteindelijk geen variabele wordt? Googlen levert vooral de vraag van het nut van 'final'.

[PrisonerOfPain]

30 tot 60 keer per seconde is niet zo heel veel zeker niet voor die code.

[Herko_ter_Horst]

1. Te triviaal om je druk over maken
2. Meten is weten

Ik acht de kans vrij groot dat de static compiler (javac) de boel al inlined, maar als die het niet doet zal de JIT/HotSpot compiler het zeker doen als dit vaker uitgevoerd wordt.

Bij 30-60 keer per second gaat het verschil niet meetbaar zijn, verwacht ik. Pas bij duizenden keren per seconde lijken dit soort micro-"optimalisaties" überhaupt interessant.

Als je wilt weten wat javac er van maakt, kun je met javap natuurlijk prima even de bytecode vergelijken van de twee opties die je noemt.

Hopelijk ten overvloede: tenzij in een realistische test is aangetoond dat een bepaald stukje code een performance bottleneck is, geldt: leesbaarheid > "optimalisatie".

[ Voor 27% gewijzigd door Herko_ter_Horst op 26-08-2014 16:29 ]

[Cilph]

Maar wordt het niet sowieso al een variabele op de stack om door te kunnen worden gegeven aan de scl() methode? Hoe zou de performance dan anders moeten zijn?

[ Voor 17% gewijzigd door Cilph op 26-08-2014 17:36 ]

[ACM]

Herko_ter_Horst schreef op dinsdag 26 augustus 2014 @ 16:24:
Ik acht de kans vrij groot dat de static compiler (javac) de boel al inlined, maar als die het niet doet zal de JIT/HotSpot compiler het zeker doen als dit vaker uitgevoerd wordt.

Ik ben er vrij zeker van dat javac er juist van af blijft. Die doet niet zoveel bijzonders. Dat gezegd hebbende, de HotSpot-compiler zal het wel vrij rap inlinen. Verder eens met je verhaal

Cilph schreef op dinsdag 26 augustus 2014 @ 17:36:
Maar wordt het niet sowieso al een variabele op de stack om door te kunnen worden gegeven aan de scl() methode? Hoe zou de performance dan anders moeten zijn?

Er zit natuurlijk wel verschil tussen eerst een waarde in een variabele opslaan en daarna die variabele weer uitlezen vs direct de boel op de stack zetten er ermee rekenen.

In termen van java-bytecode scheelt dat 2 instructies (een stor en een load). Uiteindelijk is de kans wel erg groot dat HotSpot ze weghaalt omdat ze hier niets toevoegen.

Je hebt wel kans dat het voor de GC in dit geval niets uitmaakt.

[Verwijderd]

Als je dit echt wil uitzoeken zou je kunnen kijken naar de daadwerkelijk JIT compilatie.

Zie bijvoorbeeld JITWatch

[bwerg]

Hoe zou dit überhaupt uit moeten maken voor de GC? Een lokale float-variabele staat toch helemaal niet op de heap? Het lijkt mij hooguit een optimalisatie voor minder instructies en een registertje minder in gebruik (maar zoals gezegd doet de JIT-compiler dat toch wel voor je).