52.1 Einleitung
Aufgrund der Plattformunabhängigkeit des vom Compiler generierten
Bytecodes kann dieser normalerweise nicht direkt auf dem jeweiligen
Betriebssystem ausgeführt werden. Es wird stattdessen ein eigener
Interpreter, die Virtuelle Maschine
(kurz: VM), zur Ausführung der erstellten Programme verwendet.
Interpretierter Code wird naturgemäß langsamer ausgeführt
als kompilierter, selbst wenn er in Form von Bytecodes vorliegt. Zwar
ist es prinzipiell möglich, auch Java-Programme in Native-Code
zu übersetzen (es gibt sogar einige kommerzielle Tools, die das
tun), aber dann ist es mit der Plattformunabhängigkeit aus und
das fertige Programm läuft nur noch auf einem Betriebssystem.
Während das für Applikationen in bestimmten Fällen
akzeptabel sein mag, verbietet sich diese Vorgehensweise für
Applets von selbst, denn sie laufen im Internet auf vielen
verschiedenen Browsern und Betriebssystemen. Zudem widersprechen native-kompilierte
Programme der Grundidee der plattformübergreifenden Binärkompatibilität,
die eine der herausragenden Eigenschaften von Java ist.
Heutige JREs führen den Bytecode mit Hilfe eines Just-In-Time-Compiler
(kurz: JIT) aus. Ein JIT ist ein Programm,
das den Bytecode von Methoden während der Ausführung des
Programms in Maschinencode der aktuellen Plattform übersetzt
und so beim nächsten Aufruf wesentlich schneller ausführen
kann. Vorteilhaft ist dabei, dass die Klassendateien mit dem Bytecode
unverändert ausgeliefert werden können und das Programm
seinen plattformübergreifenden Charakter behält. Nur der
Just-In-Time-Compiler ist plattformspezifisch und an ein bestimmtes
Betriebssystem gebunden. Außerdem setzt die JIT-Technologie
zur Laufzeit des Programms an und kann daher gegenüber
dem klassischen, statischen Compile-Link-Run-Zyklus anderer Programmiersprachen
im Prinzip effizienter optimieren, denn sie kann Informationen berücksichtigen,
die erst zur Laufzeit des Programms zur Verfügung stehen. In
den neuen Versionen des JDK wird der JIT übrigens als Hotspot-Compiler
bezeichnet.
Leider ist auch ein Hotspot-Compiler kein Allheilmittel gegen Performance-Probleme.
Zwar ist er heutzutage in der Lage, bestimmte Codeteile so stark zu
beschleunigen, dass ihre Ablaufgeschwindigkeit der von direkt kompiliertem
Code nahekommt. Andererseits gibt es nach wie vor genügend Gelegenheiten,
Programme zu schreiben, die inhärent langsamen Code enthalten,
der auch von einem Just-In-Time-Compiler nicht entscheidend verbessert
werden kann. Zudem ensteht durch den Einsatz des JIT ein gewisser
Overhead, der möglicherweise einen Netto-Performancegewinn verhindert,
denn das Kompilieren des Bytecodes kostet Zeit und zusätzlichen
Speicher.
Am besten ist es daher, bereits während der Entwicklung der Programme
auf die Ablaufgeschwindigkeit des erzeugten Codes zu achten. Wir wollen
uns in diesem Kapitel einige typische Java-Konstrukte ansehen, die
bei unachtsamer Verwendung zu Performance-Problemen führen können.
Gleichzeitig wollen wir Möglichkeiten aufzeigen, wie man mit
alternativem Code den Engpass umgehen und die Ablaufgeschwindigkeit
des Programms verbessern kann. Wenn man diese Regeln beachtet, ist
es selbstverständlich möglich, in Java größere
Programme zu schreiben, deren Laufzeitverhalten es mit denen anderer
Anwendungen aufnehmen kann.
