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.
