Performance-Optimierung in JAVA

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)

• 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 i0 ilt20000 i)
• s " (1)
• Interne Übersetzung des Compilers
• s new StringBuffer(s). append("").toSt
  ring() (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 i0 ilt20000 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

• Vector
• Speicherung von Listen von Objekten.
• Sequentieller und wahlfreier Zugriff.
• Implementierung des Datenpuffers als Array.
• Attribute Kapazität und Ladefaktor.
• Standard Kapazität10, Ladefaktor0 (2).
• Auch ohne Multithreading-Betrieb infolge von
  synchronized-Methoden entsprechend langsam.

11
LinkedList und ArrayList

• LinkedList
• 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
• 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()