Inhalt:
• Wieso dieser Thread ?
• Aller Anfang ist schwer. Wie fange ich überhaupt an mit Programmieren?
• Wie geht es weiter?
• Die letzen kleinen Schliffs. Wie kann ich mein Programm geschwindigkeitstechnisch verbessern?
• Vorstellungen einiger Tools zur Verbesserung und Fehlerfindung beim Programmieren

1. JD-GUI
2. Proguard
3. JProfiler
4. Findbugs
5. Checkstyle
6. PMD
7. Git/Github (Versionen System)
8. Jenkins

• Welche IDE (integrated development environment) ist die beste und welche Java-Version soll ich zum entwickeln nutzen?
• Schlusswort
• Quellen

Wieso dieser Thread?:

Da ich bereits hier im Forum einige gesehen habe, welche sich gute Hoffnungen machen so schnell wie möglich mit dem Programmieren von Java-Projekten für Bukkit, auch Plugins genannt, anzufangen, habe ich mich entschlossen diesen kleinen Guide zu machen.

Hier in diesem Guide werde ich mich speziell auf die Programmiersprache Java beziehen. Ich hoffe ich kann Vielen mit diesem Guide helfen oder wenigstens eine Hilfestellung sein. Ebenfalls hoffe ich den etwas Erfahrenen unter uns auch neue Möglichkeiten zu öffnen.

Aller Anfang ist schwer. Wie fange ich überhaupt an mit Programmieren?

Wie oft hat man schon in diesem Forum gesehen, dass Viele sich so schnell wie möglich mit der Bukkit-API befasst haben ohne eine gewisses Grundwissen zu besitzen. Von diesen oder ähnlichen Gedanken sollte man sich vorerst lösen, denn dadurch kommen oft nur schlechte Programme oder allgemein gesagt schlechte Projekte zustande.

Für den Anfang sollte man sich ein gewisses Grundwissen anschaffen. Zwar hat jeder seine Lieblingsmethode zum Lernen, doch empfehle ich hier ein Buch. Meiner Meinung nach kann man mit einem Buch besser lernen und sich dann gelernte Zeug besser einprägen. Ebenso hat man nicht die Pflicht Internet zu besitzen oder geschweige denn überhaupt ein aufgeladenes Internetfähiges Gerät zu besitzen und die ganze Zeit auf den Display oder Monitor zu schauen. Für Anfänger empfehle ich dieses Buch:

http://www.amazon.de/dp/3827244390

Es beinhaltet grobe Informationen. Meiner Meinung nach für Anfänger ein guter Anfang um sich wenigstens ein Überblick zu gestalten. Die Kapitel über eine Datenbank oder über das GUI (grafische Oberfläche) sind nicht unbedingt notwendig, aber sie könnte später einmal wichtig werden. Auf jeden Fall die Datenbank-Verbindungen zum Beispiel für Bukkit-Plugins.

Informationen allein sind nicht alles, besonders die Praxis und die Übung spielen beim Programmieren eine große Rolle. Ihr wollt doch nicht die ganze Zeit in eurem Buch oder im Internet etwas nachschlagen oder?

Ganz genau, deswegen sollte man schon ein paar Projekte erstellt haben. Ein guter Anfang hierfür wäre die Bearbeitung aller Übungen innerhalb des Buches. Wie sagt man doch so schön „Übung macht den Meister.“ Jetzt könnt ihr euch schon an kleine Kreationen wagen.

Wie geht es weiter?

In dem Buch wird ebenfalls, dass man jederzeit die Möglichkeit hat sogenannte JavaDoc’s anzusehen. Dies sind Dokumentationen über die Funktionen einzelner Methoden und deren Aufbau. So ein JavaDoc gibt es nicht nur für Java sondern auch für Bukkit.

Java: http://docs.oracle.com/javase/7/docs/api/
Bukkit: http://jd.bukkit.org/dev/apidocs/

Schaut euch am besten wenigstens das von Java an. Mit einer solchen Dokumentation entdeckt man meist neue und natürlich bessere Möglichkeiten sein Programm zu entwickeln.

Stichpunkte neue und bessere Möglichkeiten finden. Nun geht es daran mehr zu Lernen. Hierfür empfehle ich das openbook von Christian Ullenboom namens „Java ist auch eine Insel“ Link:

http://openbook.galileocomputing.de/javainsel/

Dieses Online-Buch ist so gigantisch riesig und beinhaltet einen gewaltigen Batzen von Informationen. Nach diesem Buch müsstet ihr einen Großteil über Java wissen. Doch wie vorher schon erwähnt ist Wissen nicht alles, sondern man benötigt auch ein gewisses Maß an Übung.

Nun sollte man problemlos sich an das Lernen von anderen APIs wie zum Beispiel der Bukkit-API ran machen können. Solltet ihr schon richtige Profis sein könnt ihr euch auch an den obfuscaten Code ran machen.

Die letzen kleinen Schliffs. Wie kann ich mein Programm geschwindigkeitstechnisch verbessern?

Jetzt geht es daran eurem noch einen kleinen Boost in Sachen Geschwindigkeit zu bringen. Wieso so etwas wichtig ist? Die Frage ist ganz einfach zu beantworten. Nämlich durch wenige sogenannte Laggs, womit geschwindigkeitsträchtig Zusammenbrüche gemeint sind, wirkt das Programm ansprechender für den Endbenutzer oder auch Kunde. Natürlich würden durch so manche Verbesserungen die Mindestanforderungen für die Leistungen eines Endgerätes sinken. Somit würde es ebenfalls interessanter. Man denke an so manche Spieletitel, die erschienen sind und es vorerst fast keiner spielen konnte, weil es einfach zu hohe Leistungen voraussetzt.

Somit kämen wir zu einem weiterem Punkt, nämlich der Einstellbarkeit, welche ich hier kurz ansprechen werde. Ich finde es meist eine Qual, dass einem Nutzer eines Computer-Produktes hier zu wenige Freiheiten gelassen werden. Ich weiß, dass so etwas viel Arbeit ist, aber es lohnt sich. Besonders die Möglichkeit die Grafiken umzustellen ist meiner Meinung nach eine große Wichtigkeit.

So jetzt bin ich aber etwas vom Thema abgekommen. Jetzt zum eigentlichen Punkt der Geschwindigkeitsverbesserung. Ich habe schon länger mit diesem Thema auseinander gesetzt und meiner Meinung nach ist ein solches Thema ein Punkt von großer Wichtigkeit. Wie oft habe ich mir schon Artikel aus dem Internet angesehen und ebenso selber ein bisschen mit Debuggern oder Profilern (Ein Programm als Beispiel unten) rumgespielt.

Für größere Projekte ist Java eine echt schlechte Umgebung, wenn es in Sachen Geschwindigkeit geht. Zuerst ist Java eine Objektorientierte Programmiersprache, damit wird eine starke Wartbarkeit unterstützt.

Weiterhin wird Java nicht in Maschinencode(01010) übersetzt, sondern in Bytecode also Zwischencode. Die eigentliche Übersetzung in den Maschinencode erfolgt erst beim Starten der Anwendung, dadurch es ist aber Java eine plattformübergreifende Umgebung. So eine Übersetzung, die erst beim Starten durchgeführt wird nennt man Just in Time (JIT).

Nun habe ich extra für diesen Guide ein paar Punkte rausgesucht, welche meiner Meinung nach ziemlich wirksam und ebenso einfach zum Benutzen sind. Eventuell werde ich auch etwas zu dem Punkte sagen und diese erklären, doch bei den meisten kann man einfach nicht mehr als einem Satz oder ein paar Wörter dazu sagen.

• Aneinander ketten von Strings

Strings sind final Objekte und somit nicht veränderbar. Sobald man sie verändert werden neue Objekte gebildet. Dies kann zu starken Geschwindigkeitsverlusten führen zum Beispiel beim aneinander ketten durch das +. Für mehr als 2 Strings, welche zusammen gehören sollen, empfehle ich entweder String.format, StringBuilder, StringBuffer oder Message.format.

• Niedrigste Sichtbarkeit --> weniger Zeug dem Speicher

Hierzu muss eigentlich nicht mehr viel sagen. Das müsste doch schon zu euren Programmierstandarten zugehören.

• Inlining/Final bei Methoden oder Klassen

Durch das Inlining oder durch Final bei Methode oder Klassen erzielen wir ebenfalls ein besserer Ergebnis. Denn hiermit können wir das Objekt oder die Methode als nicht überschreibar markieren. Dies bringt schon 5 % bessere Leistung und dies für grad mal 3 sek Arbeit.

• Static benutzen

Wieso soll den jede Instanz eines Objektes Zugriff auf eine Methode haben, welche sie auch so ausführen kann. Umso mehr Methoden zu einem Objekt gehören umso mehr muss auf den Speicher.

• Bessere Verwendung von volatile, synchronized und Locks

Manchmal kann auch volatile eine gute Alternative sein. Wenn oft etwas am Objekt geändert wird, ist aber synchronized die bessere Lösung. Bestimmt ist vielen bekannt, dass synchronized ziemlich viel Leistung kostet, da es immer einen Monitor anmeldet und immer die Daten abgleichen muss. Hier wären die Locks sogar eine bessere Lösung.

• Größe einer Collection angeben oder mit Arrays arbeiten

Wenn man bereits eine ungefähre Größe einer Collection weiß sollte man die Größe auch angeben, da die Vergrößerung von der Collection meist sehr viel Leistung zieht (Durch Instanziierung eines neuen Objektes) und wenn man genau Werte hat, sind Arrays die beste Lösung, da es anders herum meist zu einem großen Overhead führt.

• Bei Merfachverwendung sind sollte man in Erwähnung ziehen, dass Objekt zu klonen

Wenn man mehre Variablen benutzt, die einen gleichen Inhalt haben wie ein bereits existierendes Objekt, dann wäre es sinnvoller dieses zu kopieren anstatt ein komplett neues anzulegen.

• Bei großen TextComponenten (ebenso TextField und TextArea) hilft die Zuweisung null

Bei einer riesigen TextComponente lohnt es sich sogar bei einer Löschung die aktuelle TextComponente einfach null zuzuweisen und sie der Garbage Collection zu überlassen.

• GUI nur den Bereich neu zeichnen den man brauch (repaint)

Wieso sollte man denn alles neu zeichnen, wenn man nur einen kleinen Teil, welcher sich geändert hat, benötigt? Genau dafür gibt es auch die Methode repaint und diese sollte man dann auch benutzen.

• Im Hintergrund zeichnen

Hier kann man mithilfe eines kleinen Threads mit niedriger Priorität im Hintergrund zeichnen. Dies benötigt zwar mehr Arbeitsspeicher, aber falls der Benutzer das Feld aufruft, ist der Aufruf viel schneller.

• HashMap schneller als HashTabelle, da keine synchronized

Der Stickpunkt sagt doch schon alles.

• Bei nicht Wissen eines Typs ist die Überprüfung des HashCodes sinnvoll

Die Überprüfung des HashCodes ist viel schneller als die mithilfe von instanceof. Wenn man wirklich nicht weiß was für ein Objekt man besitzt, dann sollte man erst den HashCode überprüfen.

• Häufiges hinzufügen und löschen linked Listen benutzen

Ganz einfach. Bei linked Listen werden die Objekte

• Exception vermeiden außer bei großen Methoden

Bei größeren (die müssen dann aber auch wirklich richtig groß sein) Schleifen wäre es sinnvoller eine Exception zu provozieren anstatt ständig zu überprüfen, ob man nun am Ende ist. Ansonsten sollte man Exceptions wenn möglichst vermeiden. Laut Wikibook sollte die Wahrscheinlichkeit einer Exception unter 50% liegen.

• Methodenvariablen sind schneller

Variablen, welche innerhalb von Methoden stehen können schneller zugegriffen werden.

• Wieso viel, wenn es auch mit wenig geht ?

Für die einmalige eines Objektes muss man dies doch nicht extra in einer Variablen speichern zum Beispiel beim returnen erst das Objekt definieren und nicht vorher noch in einer Variablen speichern, die danach sowieso wieder verschwindet.

Weiterhin gibt es noch Optionen beim Kompilieren wie der automatischen Optimierung oder der Entfernung von Meta-Daten, aber beide empfehle ich nicht und kommen somit nicht hier vor.

Mehr verbesserte Möglichkeiten gibt es hier:
http://de.wikibooks.org/wiki/Das_Performance-Handbuch:_Implementierung_mit_Java
Bedenkt aber, dass Ihr möglichst nicht die Übersicht eueres Cods verschlechtert.

Vorstellungen einiger Tools zur Verbesserung und Fehlerfindung beim Programmieren

Beim Programmieren sollten natürlich auch keinen kleinen Tools fehlen. Hier stelle ich euch mal ein paar, welche ist selbst benutze oder benutzt hatte, vor. Natürlich habe ich diese Liste begrenzt. Ich will euch doch nicht in Informationen quälen. Was ich bestimmt bereits gemacht habe .

• JD-GUI

JD-GUI ist ein Decompiler für Java. Mit diesem Programm kann man ohne es zu installieren (Standalone) den fertigen kompilierten Bytecode als Quelltext ansehen. Es bietet einem die Möglichkeit sein fertig kompiliertes Projekt noch einmal anzuschauen und zu überprüfen, ob der Compiler auch den Source-Code richtig kompiliert hat.

Falls das eigene Projekt auf Daten zugreift von einer anderen Quelle, wo man den Source-Code nicht kennt oder es nicht genügend Informationen über die einzelnen Methoden gibt, ist ein Decompiler ebenfalls ein gutes Hilfsmittel um sich einfach mal selbst an die Arbeit zu machen und die Funktionen einzustudieren. So habe ich das auch bei dem Scoreboard gemacht. Ich mich durch den obfuscaten Code im Package net.minecraft.server.Version durchgewühlt. Diese Möglichkeit nutze nicht nur ich sondern auch viele Plugin-Entwickler von Bukkit haben dies bereits gemacht.

• JProfiler

Wie der Name schon sagt ist JProfiler ein Profiler. Dieser bietet einfache Möglichkeiten sein Projekt zu analysieren und womöglich rauszufinden welche Quelle denn so viel Leistung zieht. Danach kann man versuchen Alternativen zu finden und diese mit dem Original zu vergleichen.

• Findbugs

Der Name sagt doch schon alles. Findbugs ist ein Source-Code-Analysierer. Dieser überprüft euren Source-Code nach Bugs oder möglichen Fehlern. Ebenso gibt er Vorschläge wie man die Performance verbessern kann oder die Sicherheit.

• Checkstyle

CheckStyle überprüft ebenfalls den Source-Code, aber dieser gibt euch nur Tipps, wie ihr eurem Code übersichtlicher gestalten könnt.

• PMD

PMD ist eine viel, viel größerer Source-Code-Analysierer. Dieser ist eine Mischung aus Findbugs und Checkstyle. Er überprüft den Source-Code nach Bugs, gibt Tipps für bessere Sicherheit und bessere Übersicht und vieles mehr. Zum Beispiel gibt er wie komplex ihr eine Klasse gestaltet habt (in Punkten von 1-15). Meiner Meinung nach ist PMD ein richtig gutes Tool und sollte wenigstens mal ausprobiert werden.

• Git/Github

Git bzw. Github müssten vielen schon bekannt sein. Es ist ein Versionen System, dies bedeutet dass man auf einfache Weise zwischen sich die Veränderung ansehen kann um diese eventuell auch rückgängig zu machen. Github ist hier ein gutes Beispiel. Man kann den Source-Code online veröffentlich (muss man nicht unbedingt) und dort können andere Entwickler oder Teammitglieder Verbesserungen oder neue Funktionen hinzufügen.

• Jenkins

Jenkins zeigt die Veränderung eines Versionen Systems auf übersichtliche Weise und gibt Endbenutzern die Möglichkeit eine automatische kompilierte Version mit allen neuen Veränderungen herunterzuladen.

Welche IDE (integrated development environment) ist die beste und welche Java-Version soll ich zum entwickeln nutzen?

Die drei berühmtesten IDEs: Eclipse, Netbeans und IntelliJ sind den meisten bestimmt schon bekannt. Viele Tutorials benutzen meistens Eclipse als IDE und somit benutzen die Zuschauer oder Leser diese ebenfalls. Doch davon kann ich abraten. Man sollte sich nicht vom Tutorial davon beeinflussen lassen, welche IDE die jeweilige Person besitzt. Meist haben die anderen IDEs dieselben Funktionen nur unter einer anderen Tastenbelegung oder unter einer anderen Option.
Jede IDE hat ihre Besonderheiten oder Vorurteile. Hier mal zwei Beispiele: „Netbeans wäre eine IDE mit vollen Funktionen während Eclipse nur durch die Plugins genauso gut wird“ oder ein Beispiel für die Besonderheiten, dass man Netbeans und IntelliJ installieren muss, aber man Eclipse ohne Installation benutzen kann. Hierzu werde ich mich nicht äußern den meiner Meinung nach sollte man die IDE benutzen, mit der man am besten zurechtkommt. Man sollte die jeweilige IDE auf jeden Fall erst ausgiebig ausprobieren bevor man etwas gegen sie aussagt, denn viele Funktionen sind meist versteckt. Besonders bei der Fehlererkennung findet man so manche sinnvolle Erkennungen.

Ach die passende Java-Version ist auch so eine Sache. Falls man zum Beispiel mit Java 7 kompiliert kommen viele Benutzer deiner Programme an und wollen sich beschweren, weil bei denen irgendein Fehler auftritt, welchen sie selbst nicht verstehen (unsupported major.minor version). Dieser Fehler kommt daher, weil der Endnutzer noch eine etwas ältere Version von Java benutzt. Jedoch gibt es auch hier ein Problem, denn manche Funktionen gibt es in den älteren Version vom Java (JDK) gar nicht zum Beispiel gibt es bei Java 6 noch keine Möglichkeit Strings innerhalb einer Switch-Schleife zu nutzen. Deshalb muss man die Auswahl der passenden Java-Version ebenfalls überdenken. Da die meisten mindestens Java 6 besitzen und nur ein kleiner Teil noch Java 5, würde ich es empfehlen das JDK für Java 6 zu nutzen. Die Endbenutzer, welche Java 7 besitzen werden keine Probleme haben, wenn du deine Projekte mit Java 6 kompiliert hast – nur anders herum geht es nicht. Ich empfehle dies auch dringend, denn ich habe schon so häufig mitbekommen, dass sich Leute über diesen Fehler beschweren.

Schlusswort

Ich hoffe, wie ich bereits im Vorwort erwähnt habe, dass ich hoffe den Anfänger sowie den Erfahrenen helfen konnte. Gerne möchte ich auch Feedback von euch erhalten zum Beispiel was ich verbessern könnte oder was ich eventuell hinzufügen kann. Ebenso bin ich natürlich für Ergänzungen offen. Habt ihr Ideen, dann einfach los in diesen Thread rein oder soll ich vielleicht so etwas ähnliches nochmal machen? Wenn ja, welches?
Dieser Guide basiert auf eigener und Erfahrungen von Bekannten.

Quellen

• http://de.wikibooks.org/wiki/Das_Performance-Handbuch:_Implementierung_mit_Java
• Größenteils eigene Erfahrung und die von Freunden
• http://en.wikipedia.org/wiki/Java_performance
• http://java-persistence-performance.blogspot.de/2010/12/what-is-faster-jvm-performance.html
• http://www.eclipse.org/
• http://netbeans.org/
• http://www.java-forum.org/ides-tools/8-welche-ide-bevorzugt.html
• http://www.jetbrains.com/idea/
• http://openbook.galileocomputing.de/javainsel/

 

Eine Super Idee von dir Der Thread sollte gepinnt werden. Falls du irgendwelche anderen Texte genutzt hast, solltest du die Quellen noch erwähnen...

 

Danke sehr. Ich hab die Quellen nun hinzugefügt.

 

Eine richtig gute Einleitung. Ich benötige es zwar nicht mehr wirklich aber für Anfänger echt klasse.

 

Habs mal angepinnt
Sieht sehr gut aus.

 

Ich hab das mal überflogen (vor allem den Performanceteil) und doch einige echt falsche oder zumindest irreführenden Aussagen gefunden. Grundsätzlich gilt: Premature optimization is the root of all evil -- DonaldKnuth
http://c2.com/cgi/wiki?PrematureOptimization

Und auf deutsch: Frühzeitige Optimierung ist die Wurzel allen Übels. Das bedeutet, dass man durch das "Optimieren" von vermeindlich langsamen Codeteilen mehr Fehler ein baut, mehr Zeit verschwendet, als man damit je spart und das es meist ohnehin wo ganz anderst hängt.

Daher werde ich mal nach und nach auf verschiedene Aussagen von dem Tutorial eingehen und sie kommentieren.

Nach wie vor ein Mythos. OOP ist NICHT langsamer, als prozeduraler Code. Das, was da am Ende auf der CPU ausgeführt wird, würde ähnlich aussehen, wenn man die Eigenschafen von OOP z.B. in C nachprogrammiert. Die Sache ist einfach die, dass das was OOP ausmacht ohnehin in jeder prozeduralen Sprache von jedem eh nachprogrammiert werden muss. Was man hier im Quellcode sieht und was am Schluss als Maschienencode ausgeführt wird, unterscheidet sich teilweise DEUTLICH. Außerdem werden moderne Compiler immer mächtiger. Und Java ist DIE Sprache für große Projekte. Es gibt dazu kaum alternativen, die nicht mindestens langsamer sind. Die dynamische Speicherverwaltung nimmt einem unglaublich viel Arbeit ab. Für C++ typische Speicherlöcher oder Pointer-Chaos gibt es nicht (Speicherlöcher in Java sind etwas anderes, ich würde das nicht vergleichen). Und wie schon gesagt, die JVM ist hochoptimiert und führt Code teilweise sogar schneller aus, als vergleichbare native Programme (da Java zur Laufzeit verschiedene Prozessorerweiterungen erkennen kann und den Code dann darauf optimiert). Wirklich große Unterschiede merkt man erst bei mathematischen Anwendungen, da hier viele kleine Tricks mit Pointern und Speicher nicht möglich sind. Wer ein Minecraftplugin entwickelt, hat das Performanceproblem eh beim von Mojang vermurksten Servercode, das selbe in C++ würde keinen deut schneller laufen.

Auch hier stellt sich die Frage, ob das wirklich Sinn macht, einen StringBuilder auszupacken, wenn der entsprechende String z.B. nur beim Start erzeugt wird oder vielleicht einmal pro Stunde.

Wäre mir neu, dass Java inline kann. Die JVM entscheidet für gewöhnlich selbst, wenn sie Code nichtmehr anspring, sondern direkt an die entsprechende Stelle packt. 5% Leistung klingt da genauso nach Mythos. Ich wette das kommt aus irgend einem Buch, bei dem der AUtor vor Ewigkeiten mal Java gelernt hat, als das vielleicht noch so war. Ansonsten gibt es diverse Optimierungen, die die JVM während der Laufzeit durchführt um häufig verwendeten Code zu optimieren und tatsächlich kann es davon abhängen ob eine Funktion überschrieben wurde oder nicht, aber wenn man die Funktion überschreiben muss, dann muss man das halt. Der Performancegewinn ist viel zu klein als das er spürbar ist. Und außerdem wette ich auch hier, dass die Performance nicht an dieser Stelle gebremst wird, denn das passiert immer dort, wo man es eh nicht erwartet hätte.

Falsch! Methoden werden nicht mit den Membern zusammen kopiert. Die Methoden sind genau einmal pro Klasse vorhanden. Selbes Missverständniss führt auch zu der Annahme, dass OOP langsamer sei oder mehr Speicher braucht.

Auf den Stack von einem Thread + Verwaltungsdaten ist geschißen. Wenn man einen Thread braucht, dann brauch man einen Thread. Die paar kbyte machen es bei 12GB RAM auch nicht aus.

Der Punkt ist viel zu klein und nicht ausführlich beschrieben. Durch die Wahl der richtigen Datenstruktur ist man quasie alle Probleme los. Man muss einfach wissen, was man für Möglichkeiten hat und diese richtig ansetzen. Hier lässt sich meist ordentlich Performance gewinnen.

Das prüfen von einem boolean oder von ein paar Bytes wird DEFINITIV nicht der Grund sein, warum das Programm langsam ist. Lesbarkeit geht vor Performance. Außer ihr arbeitet an Echtzeitkritischen Systemen, aber da verwendet man eh kein Java. Selbiges gilt für Exceptions. Wenn ich eine Exception braucht, dann brauche ich eine. PUNKT. Auch das wird den Code nicht langsamer machen.

Das ist so hoch wie breit. Erstmal liegt das Objekt eh im Heap und nur die Referenz auf dem Stack und zweitens, kommt es auch hier wieder nicht auf die paar Bytes an. Wenn der Code dadurch besser lesbar ist, dann ist das wichtiger.


Der Rest ist ganz okay, auch wenn vieles nicht genau erklärt wird und Neulinge sich damit eher einen falschen Stil angewöhnen. Dennoch kann man es sich mal durchlesen, es sind ja auch Quellen vorhanden für das weitere recherchieren.

Troz allem gilt jedoch, dass man am Ende optmiert und nicht am Anfang. Mit einem Profiler sieht man dann auch ganz genau, wo es sich lohnt und wo halt nicht.

 

Erstmal danke für ein solch langen Kommentar, jedoch muss ich noch etwas klarstellen. Also erstens wenn du dir schon die Mühe machst und danach ein solchen Kommentar schreibst, solltest du den Beitrag nicht überfliegen. Ich bin zwar ebenfalls deiner Meinung, dass man einen größten Teil erst mit Profilern optimieren kann. Ich habe auch nicht völlig grundlos den JProfiler in die List mitaufgenommen. Ich hatte auf meinem alten PC wirklich richtig gerne den Profiler genutzt und dieser hat mir auch stark geholfen, jedoch bin ich trotzdem der Meinung, dass einige Grundoptimierungen man schon im Source-Code durchführen sollte. Diese Optimierungen fuhren bisher bei mir noch zu keinerlei Fehlern. Schliesslich gilt trotzdem diese Regel:

Java bleibt immer noch Interpreter. Zwar wird seit 5.0 der Code im Hintergrund in Maschinencode compiliert und optimiert, aber vorerst wird der Code interpretiert. Klar dass bei Minecraft Mojang schuld ist. Der selben Meinung bin ich auch wie viele andere auch in anderen Foren. Was leider Java den Ruf der langsamen Programmiersprache immer wieder einhaucht.

Ja, da hast du völlig Recht, aber im Normalfall ist dies anders.

Also laut vieler Quellen kann Java durchaus inlining und mithilfe dem Begriff final im Methoden und Klassen wird dieses automatisch gemacht. Google einfach mal daran, du wirst einige Quellen finden. Siehe zum Beispiel hier http://java-persistence-performance.blogspot.de/2010/12/what-is-faster-jvm-performance.html:

Method Average (100 operations/10 seconds) %DIF (with normal)
Normal 25533130 0%
synchronized 13383707 -93%
Block synchronized 8244087 -203%
final 26873873 +6.1%
In-lined 26816109 +5.2%
volatile 1503727 -1539%
Reflection 159069 -15646%

1. Hat Java standarmässig 1 GB als Heap und da gibt auch keine Ausnahme, wenn das Programm mal mehr braucht.
2. Ich bin der selben Meinung, dass es nicht viel im Arbeitspeicher(Es geht hier nicht um den Thread sondern um das Gezeichnete, welches ebenfalls gelagert werden muss) ist, aber trotzdem bin ich der Meinung, dass der Leser dies erfahren muss.

Ich habe damit gerechnet, dass man schon weiss was eine LinkedList ist und ich sie nur dazu erinnern möchte. Zudem wird dies als Thema in dem gennanten Buch bereits angesprochen.

Bei diesem Punkt geht es wie im Text erwähnt um richtig große Zahlen und nicht um sowas wie einer Billarden, sonder sowas wie 1.000.000.000.000.000.000. Ein kleiner try-catch Bereich macht hier nicht groß etwas an der Lesbarkeit aus.

Wenn du ein Objekt du das Objekt immer wieder mit einem Getter ansprichst. Ist dieses nicht immer das gleiche Objekt, sondern eine Kopie mit dem selben Inhalt. Zwar wird dieser nach nicht benutzen vom Garbage-Collector eingesammelt. Schön ist dies aber nicht. Ebenso schön sieht es auch nicht aus.

Der erste Teil war für Anfänger gedacht und der Rest wie dem Performance-Teil eher zur Erinnernung oder Ergänzung an die schon etwas erfahrenen. So wurde auch der Teil erst später angesprochen.