4.6  Performanz-Optimierung

Bei der Verarbeitung größerer Datenmengen, gibt es mehrere Optionen. Entweder man verlässt sich auf die Performanzoptimierung, die im XSLT- / XQuery- Prozessor implementiert ist, bzw. benutzt Methoden, wie XSLT Streaming - oder man setzt eine Ebene darunter an und schaut zu, was Java so treibt.
Es ist natürlich auch möglich seine Algorithmen umzustricken, den Code zu optimieren und das ganze (noch) kryptischer zu machen. Aber ganz nach dem Motto "Never Change a running system" wird vielerorts zunächst einmal an der Basis gefeilt.

4.6.1  Heap Memory und Garbage Collector

Wenn ich mich recht an mein Informatikstudium erinnere, dann sammelt ein Garbage Collector automatisch Speicherblöcke ein, die das Java Programm (Saxon) nicht mehr braucht und übergibt diese an die Heap Memory Verwaltung. Ein Heap ist meistens ein automatisch balanzierender Baum, der die freigewordenen Speicherblöcke der Größe nach sortiert verwaltet.
Da auch der Garbage Collector zur selben Zeit läuft, wie unser Java Programm, können sich die beiden ins Gehege kommen. Hat man für das Java Programm zuviel Heap-Space reserviert, dann lagert der Garbage Collector seine temporären Erzeugnisse auf einen langsamen Swap-Bereich aus. Hat man dagegen zuwenig reserviert, dann ist nicht genügend Platz für das Hauptprogramm vorhanden.
Gebräuchliche Fehlermeldungen sind z.B.:
  • java.lang.OutOfMemoryError: Java heap space
  • java.lang.OutOfMemoryError: GC Overhead limit exceeded
Mehr dazu steht auf der Oracle Webseite zum Thema ↗
Diese viel diskutierten Heap Einstellungen der Java Virtual Machine (JVM), wirken sich besonders bei Applikationen aus, bei denen der Speicherverbrauch zu einer bestimmten Zeit nicht vorhersehbar ist, z.b. bei einem Java-Game mit Action- und auch mal Rollenspielelementen.
Hier wäre ein Tuning bzgl. der JVM Heap Optionen angebracht, zumal man das Spiel auch für Spieler optimieren will, die nicht auf die leistungsfähigste Hardware zugreifen können.
Gängige Optionen, die man beim Java-Aufruf mitgibt, sind bspw.
  • Xms<size> set initial Java heap size
  • Xmx<size> set maximum Java heap size
  • Xss<size> set java thread stack size
Mehr dazu steht auf der Oracle Webseite zum Thema ↗
Für die batch-orientierten Prozesse bei der XML Verarbeitung sind diese Optionen meist nicht ausschlaggebend, da der Heap bei der Transformation eines grösseren Dokuments linear belastet wird. Hier ist es sogar so, dass man das obere Limit für den Heap-Speicher mit der unteren Schranke gleichsetzen sollte, um der JVM die Auswahl des geeigneten Speicherbereichs zur Laufzeit zu ersparen.
Ich benutze für meine performanzlastigen Transformationen eine 10 GB Heap Schranke:
-Xms10g -Xmx10g
Damit lassen sich auch sehr große XML Dateien mit einer Pipeline, wie MorganaXProc ↗ , die die Ergebnisdokumente der einzelnen Transformationsschritte im Speicher behalten, effizient verarbeiten.
Previous PageNext Page
Map Version: