[Java] Effectieve en snelle code

[Verwijderd]

Ik zit de laatste tijd er te denken over de code die ik schrijf.. (jah, denken!.. )
En ik heb eigenlijk toch wel trijfels in hoeverre mijn code snel en effectief is.
Laatst vertelde iemand mij bijvoorbeeld dat ipv:
string + string + string etc. etc. dus string aan elkaar plakken veel sneller kan dmv een stringbuffer.

Er zullen vast nog veel meer van dit soort manieren van coden zijn om je code veel sneller en effectiever te maken.
Weet iemand een goed boek, of een goede website waar ik dit soort informatie kan vinden?

In dit geval heb ik het over java, omdat dit de programmeertaal is die ik hoofdzakelijk gebruik, maar het kan natuurlijk ook over in het algemeen (dus wat eigenlijk voor iedere taal geldt).

[.oisyn]

waarom post je niet meer op gameskool?

[Verwijderd]

kweenie...
ik ben op dit moment niet echt bezig met games maken. (nooit echt, maar wel interessant.. )

en ik heb het de afgelopen paar weken echt gigantisch druk gehad met mijn studie en stage.(echt van 's ochtends vroeg tot 's avonds laat, en dan was ik 's avonds zo rot...)

Maar de komende tijd(na volgende) week heb ik weer meer tijd. en kom ik wel weer langs...

[GarBaGe]

Je kan (gratis) profilers download die in de gaten houden waar je je geheugen en processor tijd aan staat te verspillen.

Aantal dingen die ik weet die niet efficient zijn:
- RandomAccessFile, per byte een read-operatie. Via buffering gaat het veel sneller
- constructor van objecten kost relatief veel tijd.
- arrays (met die []-en) zijn vaak snel en efficient

[mbravenboer]

webskipper: Ik zit de laatste tijd er te denken over de code die ik schrijf.. (jah, denken!.. )

Amazing! .

En ik heb eigenlijk toch wel trijfels in hoeverre mijn code snel en effectief is.

Oei .

Laatst vertelde iemand mij bijvoorbeeld dat ipv:
string + string + string etc. etc. dus string aan elkaar plakken veel sneller kan dmv een stringbuffer.

Dat hangt er van af: als je Strings in 1 regel optelt (bijvoorbeeld System.out.println("Bla" + "Boeh" + "Bah")) wordt dit gecompileerd naar StringBuffer gebruik. Je mag dus best Strings in 1 expressie optellen.

Als je echter over meerdere statements Strings bij elkaar gaat optellen in verschillende plekken van je code, wordt deze optimalisatie niet uitgevoerd en blijft het dus inderdaad pure String optelling, die inderdaad erg duur is. Zelfs zo duur dat het catastrofale gevolgen kan hebben (zie bijvoorbeeld dit hele oude topic waarin iemand een te grote ResultSet dacht te hebben: [topic=105022/1/25] )

Er zullen vast nog veel meer van dit soort manieren van coden zijn om je code veel sneller en effectiever te maken. Weet iemand een goed boek, of een goede website waar ik dit soort informatie kan vinden?

Ja, er is een speciale website met bergen informatie:
http://www.javaperformancetuning.com/
Zie vooral hier:
http://www.javaperformancetuning.com/tips/rawtips.shtml

Dit boek schijnt ook zeer goed te zijn:
http://java.sun.com/docs/books/performance/
Je kunt het zelfs online bekijken :
http://java.sun.com/docs/books/performance/1st_edition/html/JPTOC.fm.html

[Verwijderd]

super!...bedankt!..
precies wat ik zocht

edit: (dat was trouwens ook het woord dat ik zocht: performance.. )

ps. andere websites/boek advisen zijn natuurlijk altijd nog welkom...

[.oisyn]

je kan natuurlijk ook gewoon in C++ gaan coden

^{auw, nee, niet slaan mbravenboer}

[The - DDD]

Op dinsdag 22 januari 2002 22:33 schreef OiSyN het volgende:
je kan natuurlijk ook gewoon in C++ gaan coden

^{auw, nee, niet slaan mbravenboer}

/me - DDD beukt OiSyn in elkaar.

[mbravenboer]

OiSyN: je kan natuurlijk ook gewoon in C++ gaan coden

Ik had van de lijsttrekker van leefbaar/14 een iets diepgaandere bijdrage verwacht .

auw, nee, niet slaan mbravenboer

Daar ben ik veel te zachtaardig voor .

[The - DDD]

Laat maar Martin, ik heb het al voor je gedaan.

Hmm, da's ook een goeie.

Martin en ik hebben onder tafel ( via een encrypted verbinding ) een communicatie lijn staan. Ik ben de geheime rechterhand in de duisternis die de vuile klusjes opknapt.

[toraq]

Op dinsdag 22 januari 2002 22:41 schreef The - DDD het volgende:
Laat maar Martin, ik heb het al voor je gedaan.

Hmm, da's ook een goeie.

Martin en ik hebben onder tafel ( via een encrypted verbinding ) een communicatie lijn staan. Ik ben de geheime rechterhand in de duisternis die de vuile klusjes opknapt.

Zo geheim ben je nu niet meer

[Verwijderd]

Op dinsdag 22 januari 2002 22:33 schreef OiSyN het volgende:
je kan natuurlijk ook gewoon in C++ gaan coden

^{auw, nee, niet slaan mbravenboer}

Ik wil eerst verder met java, ik begin het namelijk hoe verder ik kom java steeds leuker te vinden.
En er zal in de toekomst vast wel een moment komen dat ik c++ ook ga coden maar op dit moment ben ik druk genoeg met java..

[The - DDD]

(Dit gaat echt off-topic.)
Shit dan moet ik jullie allemaal koud maken.

[The - DDD]

In ieder geval, ik meen dat er op javasoft ergens een documentje is waarin al dit soort optimalisaties staan.

Zoek is op performance guide of iets dergelijks.

[Verwijderd]

ok, dan maar weer even on-topic.

Wie heeft er nog real-life aanbevelingen voor mij?
dus dingen die je zelf veel gebruikt en die erg goed werken...

[mbravenboer]

The - DDD: Shit dan moet ik jullie allemaal koud maken.

. Vergeet niet dat je mijn rechterhand was he? Ik blijf liever warm .

[mbravenboer]

webskipper: Wie heeft er nog real-life aanbevelingen voor mij?

dus dingen die je zelf veel gebruikt en die erg goed werken...

Er is maar 1 Universele regel: Beperkt Object creatie. Alle andere regels hebben in feite allemaal dit doel . Makkelijk te onthouden he? .

Je kan verder denken aan:
* Als je collections gebruikt: probeer de grootte in te schatten en geef deze mee aan de constructor van de verzameling.
* Gebruik Singletons als van een bepaalde klasse altijd maar 1 instantie zal zijn. Soms heb je de neiging om steeds maar een object aan te maken van die klasse als je hem nodig hebt. Singeltons zijn soms veel makkelijker en efficienter.
* Eigen modellen implementeren als je Swing gebruikt.
* Implementeer je eigen renderers in Swing.
* Wees selectief met het waarschuwen van een Swing GUI vanuit modellen. Probeer zo exact mogelijk aan te geven wat er is veranderd.
* Probeer te voorkomen dat Swing default modellen aan gaat maken. Geef gelijk je modellen mee aan de constructor als je dit toch al van plan was.
* Voorkom het creeeren van Dimensions, Points etc als er gegevens over een GUI nodig zijn: gebruik liever de varianten met primitieven.
* Multi-threading gebruiken waar mogelijk en functioneel.
* Buffer zoveel mogelijke je IO-streams

Zomaar een aantal punten, er zijn er zeker veel meer en wellicht ben ik wel belangrijke vergeten .

[.oisyn]

Op dinsdag 22 januari 2002 22:41 schreef The - DDD het volgende:
Ik ben de geheime rechterhand in de duisternis die de vuile klusjes opknapt.

D'r zijn alternatieven voor masturberen hoor

[mbravenboer]

OiSyN: D'r zijn alternatieven voor *censuur* hoor

OiSyN, ik vind je bijdrage in dit topic zeer discutabel en een light-mod onwaardig . C++ en *censuur*.... yukkie .

[.oisyn]

ik ben toekomstig lite-mod, ik mag alles

maar okee, ontopic: in de java compiler zit een optie om te optimizen... heeft dat echt gigantisch veel impact? Ik heb namelijk ooit eens vluchtig naar die JVM asm-code gekeken, en toen zag ik dat java-code aardig dicht op de asm-code lag... dus dan valt er niet veel meer te optimizen lijkt me zo

[The - DDD]

[ontopic]
CHECK DEZE LINK!!
http://www.javaworld.com/javaworld/jw-04-1997/jw-04-optimize_p.html
Pagina's vol met manieren om je code netjes te optimaliseren.
Check ook onderaan de pagina achter deze link... Staan een paar goeie tussen over dit onderwerp.

Het valt me trouwens op dat optimalisatie bij java sinds JDK 1.2 steeds minder een hot item is geworden. Toch een goed teken.
[/ontopic]

offtopic:
Ik ben natuurlijk niet iemands erotisch masseur he. Verdorie... Met koud maken bedoel ik uiteraard kelen dichtknijpen en niet ergens aan gaan lopen trekken ofzo...

Stelletje vieze sex maniakken.

[The - DDD]

Op dinsdag 22 januari 2002 23:17 schreef OiSyN het volgende:
ik ben toekomstig lite-mod, ik mag alles

maar okee, ontopic: in de java compiler zit een optie om te optimizen... heeft dat echt gigantisch veel impact? Ik heb namelijk ooit eens vluchtig naar die JVM asm-code gekeken, en toen zag ik dat java-code aardig dicht op de asm-code lag... dus dan valt er niet veel meer te optimizen lijkt me zo

Wat is het effect dan van die optimize switch? javac -O
Net in de 1.3 tooldoc gelezen. Nutteloze switch dus als ik het zo lees.

-O
Note: the -O option does nothing in the current implementation of javac and oldjavac.
Optimize code for execution time. Using the -O option may slow down compilation, produce larger class files, and make the program difficult to debug.
Prior to the Java 2 SDK, the -g and -O options of javac could not be used togther. As of the Java 2 SDK, v1.2, you can combine -g and -O, but you may get suprising results, such as missing variables or relocated or missing code. -O no longer automatically turns on -depend or turns off -g.

[Tomatrix]

Ik heb thuis een boek liggen wat alle bottlenecks in java wel aardig beschrijft, iets van 'performance tuning in java'. Morgen zal ik de precieze titel even opgeven.

In de Websphere Application Developer (de nieuwe IDE van IBM) zit trouwens standaard een geintegreerde profiler...

[.oisyn]

Op dinsdag 22 januari 2002 23:27 schreef The - DDD het volgende:

[..]

Wat is het effect dan van die optimize switch? javac -O

dat was dus mijn vraag, slimmerik

[mbravenboer]

OiSyN: in de java compiler zit een optie om te optimizen... heeft dat echt gigantisch veel impact?

Naar mijn weten doet deze tegenwoordig precies niets.

Ik heb namelijk ooit eens vluchtig naar die JVM asm-code gekeken, en toen zag ik dat java-code aardig dicht op de asm-code lag...

Inderdaad, Java-Bytecode is praktische hetzelfde als Java. Ik zie het dan eigenlijk ook als getype-checkte Java.

Ik wil binnenkort een taaltje naar Java-bytecode gaan compileren, maar eigenlijk heeft dat niet veel nut: je kunt net zo goed Java nemen.

dus dan valt er niet veel meer te optimizen lijkt me zo

Nou ja, je kunt natuurlijk ook een optimalisatie stap van Java -> Java doen, maar je kunt daarbij geen rekening houden met platform-specifieke instructies en performance verschillen. Dat is een taak voor de Hotspot Just-in-time compiler. Deze doet bijvoorbeeld wel aan inlining en dergelijke.

Je kunt echter best het een ander optimaliseren: inlining van final methoden, contstante propagatie, loop-optimalisering en unfolding, constant-folding kan je allemaal uitstekend doen in principe....

[The - DDD]

Op dinsdag 22 januari 2002 23:28 schreef OiSyN het volgende:

[..]

dat was dus mijn vraag, slimmerik

Ding doet niks. En in de 1.4 release candidate staat ie ook niet vermeld in de tool doc van javac. Waarschijnlijk eruit gesloopt.

[Tomatrix]

Op dinsdag 22 januari 2002 23:30 schreef mbravenboer het volgende:

Je kunt echter best het een ander optimaliseren: inlining van final methoden, contstante propagatie, loop-optimalisering en unfolding, constant-folding kan je allemaal uitstekend doen in principe....

Wanneer je elke klasse of methode die je niet derived/override final maakt, geeft dat een ongelofelijke performance boost in java.

[The - DDD]

Check dit dan:

http://www.javaperformancetuning.com/

LOL!!

[mbravenboer]

Tomatrix: Wanneer je elke klasse of methode die je niet derived/override final maakt, geeft dat een ongelofelijke performance boost in java.

Exact: dat is dus niet zo verwonderlijk. Of dat echter een fraaie optimalisatie is weet ik niet zo... Je sluit mogelijkheden voor inheritance dan wel heel erg hard af. Voor eigen producten kan dit nog wel, voor libraries zou ik het zeker niet doen. In C# zijn methode dus trouwens standaard niet virtual (niet-final dus). De meeste mensen die ik ken zetten echter overal virtual voor. Ik vind het dan ook geen goede beslissing .

[mbravenboer]

The - DDD: Check dit dan

Lees jij weleens een thread of filter je mijn posts standaard weg? .

[Tomatrix]

Op dinsdag 22 januari 2002 23:39 schreef mbravenboer het volgende:

[..]
Of dat echter een fraaie optimalisatie is weet ik niet zo...

Hehe, als alles af is en de performance is niet je van het, ga ik alle klasses 's langs en zet dan overal final voor waar dit kan, inderdaad verdient dit geen schoonheidsprijs

[.oisyn]

idd een goed punt wat ik echt compleet ben vergeten toe te passen op mijn 3d engine

na ja je ken nie alles goed doen (ding draait al bij klant, verder niet meer naar om kijken )

[Tomatrix]

Op dinsdag 22 januari 2002 23:46 schreef OiSyN het volgende:
idd een goed punt wat ik echt compleet ben vergeten toe te passen op mijn 3d engine

na ja je ken nie alles goed doen (ding draait al bij klant, verder niet meer naar om kijken )

Pfff, ff nieuw jar filetje eroverheen kopieren als ze ff niet kijken he, en let maar op hoe blij ze zullen zijn!

[.oisyn]

de sourcecode ligt op m'n ex-stageplaats waar ik dus niet meer werk, en bovendien heb ik het wachtwoord van die ftp server niet (meer)

SPAM: http://www.xs4all.nl/~oisyn/applets/homeboxx3d.html

[The - DDD]

Op dinsdag 22 januari 2002 23:41 schreef mbravenboer het volgende:

[..]

Lees jij weleens een thread of filter je mijn posts standaard weg? .

Ik had wel door dat je het boek genoemt had, maar nog geen link.

[Verwijderd]

Op woensdag 23 januari 2002 09:39 schreef The - DDD het volgende:

[..]

Ik had wel door dat je het boek genoemt had, maar nog geen link.

ja ja ...

[Alarmnummer]

Even een algemene optimaliseer regel:

ga pas optimaliseren als het nodig is. Het heeft geen nut als je 1.000 ipv 100 actions per seconde kan verwerken. Je moet dus eerst uitzoeken waar en of er geoptimaliseerd moet worden.

Want ik zie te vaak dat mensen dingen gaan optimaliseren die niet nodig zijn en de code word er vaak (hoeft niet altijd) lelijker van.

ps: ik dacht dat ik hier redelijk veilig was op GoT maar wat ik in dit topic allemaal wel niet hoor over elkaars rechterhand zijn ik denk dat ik hier minder vaak ga komen (en dan bedoel ik niet met komen wat jullie met komen bedoelen).. pfffff... lastig zeg!!

[Alarmnummer]

Op dinsdag 22 januari 2002 23:34 schreef Tomatrix het volgende:

[..]

Wanneer je elke klasse of methode die je niet derived/override final maakt, geeft dat een ongelofelijke performance boost in java.

Dat was geloof ik voor jdk1.4 zo. Maar jdk1.4 kijkt zelf of een methode niet meer overriden wordt en maakt hij hem alsnog final. Ik weet dit niet zeker, maar er staat me nog heel vaag iets bij.. ik zal het even opzoeken.

[Bobco]

Op dinsdag 22 januari 2002 22:57 schreef mbravenboer het volgende:

[..]
Als je collections gebruikt: probeer de grootte in te schatten en geef deze mee aan de constructor van de verzameling.

Ga bij een collection ook altijd bij jezelf te rade hoe je het ding gebruikt: is het 1 keer initialiseren en verder alleen maar lezen? Kun je met keys werken? Er is een FastHashMap in de Jakarta Commons Collections die je om kunt zetten naar Fast mode: lezen gaat dan opeens stukken sneller.

[Alarmnummer]

Op woensdag 23 januari 2002 10:17 schreef Bobco het volgende:

[..]

Ga bij een collection ook altijd bij jezelf te rade hoe je het ding gebruikt: is het 1 keer initialiseren en verder alleen maar lezen? Kun je met keys werken? Er is een FastHashMap in de Jakarta Commons Collections die je om kunt zetten naar Fast mode: lezen gaat dan opeens stukken sneller.

Ik ga deze meteen even checken

Het is inderdaad belangrijk hoe je collections gaat gebruiken. Bv hashcollections kunnen soms enorme performance boost veroorzaken.

[Tomatrix]

Ik heb nog even de naam van dat boek over java performance tuning opgezocht:

titel: Java Performance Tuning
auteur: Jack Shirazi
uitgever: o'reilly
isbn: 0-596-00015-4

[Verwijderd]

hmmm..best interessant boek.
maar fl 92,99 bij Bol.
Misschien ga 'k wel kopen...