From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- .../hjp5/html/k100313.html | 172 +++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 Master/Reference Architectures and Patterns/hjp5/html/k100313.html (limited to 'Master/Reference Architectures and Patterns/hjp5/html/k100313.html') diff --git a/Master/Reference Architectures and Patterns/hjp5/html/k100313.html b/Master/Reference Architectures and Patterns/hjp5/html/k100313.html new file mode 100644 index 0000000..733a4a3 --- /dev/null +++ b/Master/Reference Architectures and Patterns/hjp5/html/k100313.html @@ -0,0 +1,172 @@ + + + +Handbuch der Java-Programmierung, 5. Auflage + + + + + + + + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage +
 <<  +  <   +  >   + >>  + API  +Kapitel 50 - Performance-Tuning +
+
+ + + + +

50.1 Einleitung

+
+ +
+ +

+Java gilt gemeinhin als Sprache, die mit Performance-Problemen zu +kämpfen hat. Nicht nur die Ablaufgeschwindigkeit des Compilers +und anderer Entwicklungswerkzeuge, sondern vor allem die der eigenen +Programme läßt oft zu wünschen übrig. Aufgrund +der Plattformunabhängigkeit des vom Compiler generierten Bytecodes +kann dieser normalerweise nicht direkt auf dem jeweiligen Betriebssystem +ausgeführt werden. Er verwendet statt dessen einen eigenen Interpreter, +die Virtuelle Maschine (kurz: VM), +zur Ausführung der erstellten Programme. + +

+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, die im Internet auf vielen verschiedenen Browsern +und Betriebssystemen laufen müssen, von selbst. Zudem konterkarieren +native-kompilierte Programme die Grundidee der plattformübergreifenden +Binärkompatibilität, die eine der herausragenden Eigenschaften +von Java ist. + +

+Eine Alternativlösung bieten Just-In-Time-Compiler +(kurz: JIT), deren Entwicklung in großen +Schritten voranschreitet. 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 erhält. Nur der Just-In-Time-Compiler ist plattformspezifisch +und an ein bestimmtes Betriebssystem gebunden. Nahezu alle Hersteller +kommerzieller Java-Produkte haben mittlerweile einen JIT als festen +Bestandteil ihres Java-Entwicklungssystems eingebunden. Auch SUN liefert +seit dem JDK 1.1.6 den Just-In-Time-Compiler von Symantec als festen +Bestandteil des JDK aus. + +

+Leider ist auch ein Just-In-Time-Compiler kein Allheilmittel gegen +Performanceprobleme. Zwar ist er in der Lage, bestimmte Codeteile +so stark zu beschleunigen, dass ihre Ablaufgeschwindigkeit der von +kompiliertem C-Code nahekommt. Andererseits gibt es nach wie vor genügend +Möglichkeiten, 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. + +

+Des weiteren ist zu bedenken, dass zur Laufzeit eine Vielzahl von +Checks durchgeführt werden müssen, die die Ablaufgeschwindigkeit +von Java-Programmen vermindert: +

+ +

+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 Engpaß umgehen und die Ablaufgeschwindigkeit +des Programms verbessern kann. Wenn man diese Regeln beachtet, ist +es durchaus möglich, in Java größere Programme zu +schreiben, deren Laufzeitverhalten auf aktuellen Rechnern absolut +akzeptabel ist. +

+ + + + + + + + + +
+ +

+Wir wollen uns in diesem Kapitel nicht mit grundlegenden Techniken +der Codeoptimierung beschäftigen. Auch wenn sie zeitweilig kurz +angedeutet werden, können diese Themen besser in Büchern +über Programmiersprachen, Algorithmen oder Optimierungstechniken +für Compiler nachgelesen werden. Auch Tipps & Tricks, die +in aller Regel nur marginale Verbesserungen bringen, oder langsamer +Code, für den keine einfach anzuwendenden Alternativen bekannt +sind, sollen hier nicht behandelt werden. Statt dessen wollen wir +uns auf einige große Themenkomplexe konzentrieren, die leicht +umzusetzen sind und in der Praxis schnell zu Verbesserungen führen.

 + + + + +
 Hinweis 
+
+

+ + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage, Addison +Wesley, Version 5.0.1 +
 <<  +  <   +  >   + >>  + API  +© 1998, 2007 Guido Krüger & Thomas +Stark, http://www.javabuch.de +
+ + + -- cgit v1.2.3