Archief - java optimizaton

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Massie

Legacy Member
Ik ben bezig met een klein projectje met een vriend en we zijn op een stadium gekomen dat een deel af is en dat we iets werkend hebben, nog niet het complete programma, maar het heeft bruikbare functionaliteit dat solo al af zou kunnen zijn maar gewoon te beperkt. Willen we nu starten met dinge efficienter te maken. Zijn er van die mainstream en ook geavanceerdere tricks en tips waar ge u code best aan kunt laten voldoen om het effiencient te houden? Compileer tijd te verminderen, minder cpu usage.

passero

Legacy Member
Ik gebruik VisualVM wat een heel goeie tool is om hotspots te vinden. Je moet wel wat plugins downloaden eerst.

Je kan terwijl je het programma test, de profiler laten lopen op CPU. Dan kan je een filter instellen op jouw packages en zien hoelang elke methode in totaal de CPU nodig heeft. Je kan ook zien hoeveel keer elke methode aangeroepen is. Op die manier kan je de gemiddelde CPU time/call berekenen en kijken om de methodes te optimaliseren die het meest aangeroepen worden.

Als je die gebruikt moet je wel altijd naar de CPU (self time) kijken. Dat is de tijd dat de methode de CPU gebruikt.

Ik gebruik dit altijd bij klanten om performantie problemen op te sporen en het heeft me nog nooit in de steek gelaten. De interpretatie van de gegevens is wel niet altijd evident maar als het op eigen geschreven code is moet het wel een stuk gemakkelijker gaan.

Jerre Muesli

Legacy Member
Objecten compact houden, caching gebruiken, Stringbuilders, .. en vooral slim programmeren (geen domme dingen in loopjes doen).
Compile time maakt geen zak uit. Dat heeft geen directe impact op uw programma.

Massie

Legacy Member
visualvm ziet er inderdaad wel interessant uit, zeker nuttig en ga ik gebruiken, bedankt daarvoor.

Op het moment lijkt het dat er nog een domme/onnodige functies, classes en ongebruikte variabelen zijn.
Er is een moment dat ik een mail stuur dat het programma meer tijd nodig heeft dan ik geduld heb. Is het mogelijk om de interface verder te laten lopen op de ene core en het zenden van de mail op een andere core? Dat de gebruiker geen lag ondervind?

passero

Legacy Member
Normaal doe je dat door multithreading. Heeft niet per se iets met cores te maken. Je moet gewoon een apparte thread maken die de mail verstuurd en dan kan het programma gewoon verder.

Massie

Legacy Member
ik heb voor mijn mail een apparte thread gemaakt en werkt nu inderdaad zonder lag. Ik dacht daar al aan mor overschachte de nodige code een beetje. Java zal zijn argumenten niet altijd by reference doorgeven, is er een manier om dit te omzeilen dat er toch minder geheugen word gebruikt zonder de code onoverzichtelijk en slordig te maken?

passero

Legacy Member
Java geeft ALTIJD objecten door als referentie tenzij het primitieve types zijn...
Dus daar kunt ge weinig aan doen dus dat is al optimaal voor u geheugen gebruik.

VisualVM kan u trouwens ook cijfers geven van hoeveel instances ge hebt van iedere klasse en hoeveel bytes die in totaal innemen. Ook handig voor tuning.

NoGo

Legacy Member
passero zei:
Java geeft ALTIJD objecten door als referentie tenzij het primitieve types zijn...
Dus daar kunt ge weinig aan doen dus dat is al optimaal voor u geheugen gebruik.

VisualVM kan u trouwens ook cijfers geven van hoeveel instances ge hebt van iedere klasse en hoeveel bytes die in totaal innemen. Ook handig voor tuning.

Java is toch altijd pass by value? De referentie van het object wordt by value doorgegeven?

Jerre Muesli

Legacy Member
Java is altijd by value. Int geval van objecten is de value gewoon de reference.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan