Performance-Optimierung in JAVA

Präsentation zum Thema: "Performance-Optimierung in JAVA"—  Präsentation transkript:

1 Performance-Optimierung in JAVA
Bernegger Hans Peter Klinger Andreas Schneider Martin

2 Themen Geschwindigkeit von Java-Programmen,
Interpretierter und kompilierter Code, Tuning von String-Zugriffen, Verwendung von Vektoren und Listen, Tuning von Dateizugriffen, Aspekte der Speicheroptimierung in Java, Profiling.

3 Überblick (1) Charakteristika von Java;
Verarbeitung von Zeichenketten: Langsame String-Verkettung, Optimierte String-Verkettung, Weitere String-Operationen, StringBuffer-Methode toString(); Vektoren und Listen: Die Klasse java.util.Vector,

4 Überblick (2) Dateizugriffe; Speicheroptimierung; Profiling:
ArrayList und LinkedList; Dateizugriffe; Speicheroptimierung; Profiling: Profiling-Grundlagen, Einsatz eines Profilers; Allgemeine Verbesserungen.

5 Charakteristika von Java
Plattformunabhängigkeit; Just-In-Time-Compiler (JIT): Schnellere Ausführung von Methoden; Performance-Einbußen durch Checks bei Bereichsüberschreitungen bei (Arrays, Strings), Dereferenzierung von Zeigern gegen null, Zuweisungen von Objektinstanzen, vielen arithmetischen Operationen.

6 Langsame String-Verkettung
Sample-Java-Code: String s = ""; for (int i=0; i<20000; i++) s += “*"; (1) Interne Übersetzung des Compilers: s = new StringBuffer(s) append("*").toString(); (1*) 60000 temporäre Objekte, wdh. Kopieren der Zeichen im StringBuffer-Konstruktor.

7 Optimierte String-Verkettung
Sample-Java-Code: StringBuffer b = new StringBuffer(1000); for (int i=0; i<20000; i++) b.append(“*“); (2) String s = b.toString(); Vorteile: Aufruf von (2) meist in konstanter Zeit, Faktor 10 schneller, 60000 temporäre Objekte weniger.

8 Weitere String-Operationen
Einfügen in Strings: s = "*" + s; b.insert(0, "*"); Faktor 4 und keine temporären Objekte. Löschen in Strings: s = s.substring(0, 1000) + s.substring(2000); s = b.delete(1000, 2000).toString(); Löschen anstelle von Verbinden.

9 StringBuffer-Methode toString()
Kein Kopiervorgang beim Aufruf, derselbe verwendete Puffer, shared-Flag im StringBuffer-Objekt, Abfrage bei verändernden StringBuffer-Methoden und ev. Kopieren vor der Veränderung; echter Kopiervorgang erst nötig bei schreibendem Zugriff auf den StringBuffer.

10 Die Klasse java.util.Vector
Speicherung von Listen von Objekten. Sequentieller und wahlfreier Zugriff. Implementierung des Datenpuffers als Array. Attribute Kapazität und Ladefaktor. Standard: Kapazität=10, Ladefaktor=0 (=2*). Auch ohne Multithreading-Betrieb infolge von synchronized-Methoden entsprechend langsam.

11 LinkedList und ArrayList
Implementierung als doppelt verkettete Liste. Keine Kopiervorgänge beim Erweitern. Vielzahl der allozierten Objekte. ArrayList: Implementierung ähnlich wie Vector. Infolge fehlender synchronized-Attribute sehr hohe Performance.

12 Dateizugriffe (1) Writer-Klassen: Verarbeitung von Character-Streams.
16-Bit breite UNICODE-Zeichen. Kapselung in einen BufferedWriter. Meisten externen Dateien arbeiten mit 8-Bit-Zeichen  Konvertierung durch Methoden der Klasse sun.io.CharToByteConverter.

13 Dateizugriffe (2) OutputStream-Klassen: RandomAccessFile:
Arbeiten mit Bytes anstelle von Zeichen. Keine aufwendige Konvertierung. Ausgabe der niederwertigen 8 Bit je Zeichen. RandomAccessFile: Ungepufferter Byteweiser Zugriff langsam. Verarbeitung eines ganzen Arrays von Bytes. int num = file.read(buf);

14 Speicheroptimierung Jede Allozierung kostet Rechnerzeit.
Objekte recyceln. Nicht mehr referenzierter Speicher. Große Mengen an temporären Objekten. Objektreferenzen  OutOfMemoryError. System.gc(); Variablen explizit Wert null zuweisen.

15 Profiling-Grundlagen
Überwachung und Messung: Performanceparameter (z.B. CPU-Zeit), Anzahl der allozierten Objekte, Anzahl der Aufrufe bestimmter Methoden. Profiler-API: JVMPI. Beispielimplementierung hprof: Brauchbares, aber rein textuelles Analyse-Tool.

16 Einsatz eines Profilers
Programm mit Option –Xrunhproof starten. Größen Rechenzeit- und Speicherverbrau-cher werden ermittelt, und über ihre Stack-traces wird folg. in LOG-File geschrieben: Woher werden sie aufgerufen? Wie tragen sie zum Programmergebnis bei? Programm kann verbessert werden. Zufriedenstellend oder erneut von vorne.

17 Allgemeine Verbesserungen (1)
Hoher Anteil von lokalem Code am Rechenzeitverbrauch: Vermindern der Anzahl von Schleifendurchläufen, Verwendung von Ganzzahlen, Herausziehen von schleifeninvariantem Code, Vermeiden der Doppelauswertung von gemeinsamen Teilausdrücken, Wiederverwenden bekannter Teilergebnisse,

18 Allgemeine Verbesserungen (2)
Verwendung alternativer Datenstrukturen, Eliminieren von unbenutztem Code, Reduzieren der Stärke von Ausdrücken. Hoher Anteil in Untermethoden: Verminderung der Aufrufhäufigkeit, Ersetzung durch performantere Aufrufe, Erhöhung der Ablaufgeschwindigkeit. System.currentTimeMillis();