www.Bastie.de

Make Java - Performance

Teil 1
Allgemeines

Warum ist Java langsamer

Da Sie dieses Dokument lesen sind Sie entweder sehr wissbegierig oder wollen Ihre Anwendungen performanter machen (Entwickeln / Implementieren / Ablaufen lassen). In beiden Fällen ist es wichtig zuerst zu wissen, warum Java Bytecode langsamer ist als viele andere ausführbaren Anwendungen.
Java ist eine objektorientierte Sprache. Objektorientierung führt leider meist zu Anwendungen, welche nicht ganz so performant sind. Dafür sind (gut) objektorientierte Anwendungen meist besser wartbar. Ein OO-Objekt muss nun einmal nach den Informationen gefragt, diese können Ihm nicht einfach entrissen werden. Der zweite wichtige Punkt ist, dass die Anwendung erst zur Laufzeit in Maschinencode übersetzt wird. Dies ermöglicht zwar die Anwendung auf jeder geeigneten JRE ausgeführt werden kann (also plattformübergreifend) jedoch dort jeweils zuerst übersetzt werden muss. Bei älteren JRE kommt noch das Fehlen von JIT Compilern bzw. des Hot Spot Compilers hinzu.
Ein weiterer Grund liegt in der Art wie Java konzipiert wurde. Java sollte eine sichere Sprache werden. Dies führt u.a. dazu, dass bei jedem Objektzugriff zur Laufzeit geprüft wird, ob eine gültige Referenz vorliegt. Sonst kommt die geliebte NullPointerException. Zugriffe auf Arrays und Strings werden ebenfalls zur Laufzeit geprüft. Der Zugriff auf ein Element außerhalb des Gültigkeitsbereich führt auch hier zu einer Exception (z.B. ArrayIndexOutOfBoundsException). Typanpassungen oder auch Casts werden zur Laufzeit geprüft. Neben der Exception die hier auftreten kann, bedeutet dies auch, dass für jedes Objekt im Speicher noch Metainformationen vorhanden sind. Referenzen auf Methoden und Attribute erfolgen (meist) über den Namen. Dies erfordert zur Laufzeit eine Prüfung auf deren Vorhandensein und führt ggf. zu einer NoSuch...Exception.
Es gibt jedoch auch Vorteile. Sofern sich die Systemarchitektur ändert, haben Sie keinerlei Auswirkungen auf den Bytecode zu fürchten. Anders ausgedrückt wollen Sie Ihren Bytecode auf einem anderen Betriebssystem ausführen benötigen Sie lediglich eine entsprechende JRE. Eine C-Anwendung müssten Sie zumindest neu übersetzen. Und bei Assembler haben Sie beispielsweise Probleme, wenn Sie Ihre Anwendung auf einen anderen Prozessortyp portieren müssen.

Gute Gründe nicht zu optimieren

Es gibt sehr gute und triftige Gründe nicht zu optimieren. Meist steht der Punkt Optimierung der Anwendung erst dann an, wenn das Programm fehlerfrei lauffähig ist. Bei kleinen Anwendungen ist dies auch ein probates Mittel, da die Machbarkeit hier im Vordergrund steht. Dies führt jedoch zu einigen Gründen, warum Sie nicht optimieren sollten.
Bei der Optimierung Ihrer Anwendung kann viel Zeit und Geld investiert werden, ohne dass es zu spürbaren Veränderungen kommt.

Optimierungen können zu schlechter lesbaren und wartbaren Quelltext führen.
Optimierungen können zu neuen Fehlern in Ihrer Anwendung führen.
Optimierungen sind meist Abhängig von Compilern, Ausführungsplattform und anderen Teilen der Anwendungsumgebung.
Der / Jeder Objektorientierungsgedanke geht bei der Optimierung verloren.

Keiner dieser Punkte muss Ihre Anwendung betreffen; Sie sollten jedoch vorher abwägen, ob es sinnvoll ist eine Optimierung durchzuführen, wenn die Anwendung in einer Art und Weise lauffähig ist die keinerlei (Performance)-Problem hervorruft.

Gründe zu optimieren

Wenn Sie Ihre Anwendung optimieren müssen dann liegt es meist an diesen Punkten

Ihre Anwendung benötigt zu viele Ressourcen:
1. Speicher
2. Prozessorkapazität
3. Bandbreite
Ihre Anwendung findet aufgrund dieses Problems keine Akzeptanz.
Ihre Anwendung erfüllt nicht die Anforderungen des Auftraggebers.
Ihre Anwendung ist ohne Optimierung nicht sinnvoll lauffähig.

Bei jedem dieser Punkte ist dann zuerst einmal Analyse zu betreiben, wo der eigentliche Schwachpunkt liegt und wie dieser aus dem Weg geräumt werden kann. Dieses Dokument teilt sich dabei in die drei wesentlichen Teile auf, in welchen eine Optimierung sinnvoll ist: System und Umgebung, Design und Implementierung.

Wann sollten Sie optimieren?

Im Abschnitt „Gründe zu optimieren“ sind bereits wesentliche Punkte die für das Optimieren aufgezählt worden. Wenn wir diesen Abschnitt mit dem Abschnitt „Gute Gründe nicht zu optimieren“ vergleichen lassen sich schon einige Grundregeln für den Zeitpunkt einer Optimierung festlegen.
Performanceoptimierungen sollten nur dann durchgeführt werden, wenn es zu einem Ressourcenengpass, mangelnder Akzeptanz (durch Benutzer oder Auftraggeber) oder zu keinem sinnvoll lauffähigen Produkt kommt.
Ein weiteres Ziel ist sollte es sein Optimierungsmöglichkeiten außerhalb der Anwendungserstellung zu nutzen. Um diese jedoch wirksam testen zu können, ist zumindest ein funktionierender Prototyp Voraussetzung. Auf jeden Fall sollten nötige Performanceoptimierungen vor der eigentlichen Anwendungsauslieferung erfolgen. Die Performanceoptimierung sollte schließlich zuerst auf das Design zielen bevor die Implementierung in das Visier rückt. Dies hat einige weitere Vorteile. Ein gutes und performantes Design erhöht die Wartbarkeit einer Anwendung erheblich. Bei Performancegewinnen durch Änderung des Design entsteht kein „Trashcode“. Natürlich ist hier insbesondere darauf zu achten, das die Designoptimierung nach Möglichkeit nicht zu einem schlechten Design führen sollte. Der Einbau eines Cache oder Objektpools in das Design ist sicherlich positiv zu bewerten, während der direkte Zugriff auf Variablen ebenso wie die Auflösung der Trennung von Anwendung und Oberfläche (Stichwort MVC) eher in den Teil schlechtes Design fällt.
Bleib zum Schluss nur noch die Feststellung, dass in der Analysephase keine Performanceüberlegungen durchgeführt werden. Hier geht es um die fachlichen Anforderungen die Ihre Anwendung bewältigen muss, nicht deren Umsetzung.

Wo sollten Sie optimieren?

Es gibt drei wesentliche Ansatzpunkte, um Ihre Anwendung performanter zu gestalten. Sie können Optimierungen in der Anwendungs- / Systemumgebung vornehmen, im Design und in der Implementation. Jeder dieser Punkte hat seine Vor- und Nachteile und Daseinsberechtigung. Grob kann man diese Teile wie folgt umreißen:
Optimieren der Anwendungs- bzw. Systemumgebung (Laufzeitumgebung) bedeutet (meist) ohne direkten Eingriff in die Anwendung. Der Eingriff kann z.B. beim Wechsel der Datenbank nötig sein. Optimierungen werden dabei speziell auf die jeweilige Umgebung abgestimmt und sind nur selten auf andere Systeme übertragbar. Beispiele wären der Einsatz einer anderen JRE oder Datenbank oder auch das Erhöhen des Umgebungsspeichers für die Java Virtuelle Maschine.
Optimieren des Designs bedeutet fast immer einen grundsätzlichen Umbau der Anwendungsstruktur. Dies zieht somit auch Implementierungsarbeiten nach sich. Der Vorteil ist jedoch, das der Quelltext zu einem hohen Anteil eins zu eins in die neue Struktur übernommen werden kann (Copy & Paste) oder nur geringe Anpassungen nötig sind. So kann der Einbau eines Cache innerhalb einer Klasse auch ganz ohne Änderung der Abhängigen Strukturen erfolgen. Hier bietet sich auch der Einsatz von bestimmten Entwurfsmusterns an.
Die Optimierung in der Implementation (hier ist nicht die Folgearbeit nach Designoptimierung gemeint) soll schließlich schnelleren Quelltext erzeugen, ohne dass dieser nicht mehr wartbar wird. Dies bedeutet meist Optimierung des Algorithmus.
Obwohl ich hier bewusst von einigen Optimierungsmöglichkeiten, wie direkten Zugriff auf Objektvariablen, abrate, werden auch diese Möglichkeiten im Laufe dieses Dokumentes zur Vollständigkeit näher besprochen.

Was sollten Sie optimieren

Wo und Was greift natürlich sehr ineinander. Zuerst also noch einmal „Wo sollten Sie optimieren?“ - in der Anwendungsumgebung, in dem Design und in der Implementierung. Während Sie sich bei der Anwendungsumgebung und im Design keinerlei Grenzen zu stecken brauchen, ist bei der Implementierung, also dem Quelltext, etwas mehr Vordenken gefordert.

Die 80 / 20 Regel

Eine Feststellung die sich in den Jahren seit den ersten Programmzeilen herauskristallisiert hat, ist, dass 80% der eigentlichen Aufgabe einer Anwendung in etwa 20% des Quelltextes erledigt wird. Typisches Beispiel dafür ist eine Schleife. Schleifen, insbesondere häufig durchlaufende, enthalten in sich Quelltext der während der Anwendung wesentlich häufiger ausgeführt wird. Es ist daher sinnvoller diesen Teil zu optimieren, als den umliegenden Quelltext. Das Problem welches sich dann meist stellt, wie findet man diese 20% Quelltext. Wie schon erwähnt sind Schleifen immer besonders scharf zu betrachten. Des weiteren hilft der Einsatz von Profilern. Profiler sind Anwendungen, welche in der Lage sind die Performanceeigenschaften andere Anwendungen zu messen. Dank Sun steht Ihnen mit dem JDK ein einfacher Profiler schon zur Verfügung.

Wann sind Sie fertig mit der Optimierung?

Ein Ende der Optimierungsarbeiten ist grundsätzlich nie bzw. genau dann erreicht, wenn Ihre Gründe zu optimieren nicht mehr bestehen. Selbst dann kann jedoch wieder ein Optimierungsbedarf neu entstehen. Je nach entwickelter Anwendung gibt es jedoch noch Unterschiede zu beachten.

Applets und Servlets

sind kritische Anwendungen. Hier ist die eigentliche Anwendung die es zu überprüfen gilt die Präsenz im Netz (Intranet, Internet oder was auch immer). Diese muss mittels geeigneter Werkzeuge (Profiler) einem ständigen Überprüfungsprozess unterliegen. Hierbei kann es sich dann ergeben, dass eine bis dahin gute Javaanwendung plötzlich zum Performanceproblem wird.

Applikationen

sind hingegen relativ leicht zu handhaben. Hier gilt der Grundsatz: Wenn die Gründe wegfallen, kann die Optimierung als abgeschlossen angesehen werden.

Beans

sind die wahre Herausforderung. Ein Bean kann nicht schnell genug sein. Beans sind wie auch Applets und Servlets Teil einer größeren Anwendung. Und hier liegt das Problem. Ein Bean, welches des Flaschenhals in Sachen Performance ist, wird auf Dauer keine Verbreitung finden. Hier liegt das Problem in der Abhängigkeit anderer Entwickler von Ihrer Anwendung. Sollte sich Ihr Bean also als unperformant herausstellen wird sich irgendwann einer dieser Fachleute hinsetzen und eine eigene Entwicklung mit gleichem Ziel vorantreiben.
Neben diesen grundsätzlichen Anmerkungen gilt natürlich, dass Aufwand und Nutzen in einem gesunden Verhältnis stehen sollten.

Teil 0 Inhaltsverzeichnis Teil 2

Java Cobol Software Resourcen Service Links Über mich Zum Gästebuch Forum