Java, XML und Performance

XML ist ein populäres Datenformat für den Datenaustausch zwischen Systemen. Der Vorteil von XML ist, es gibt sehr stabile Parser. Aber wie sieht es mit der Performance aus? Folgende Aufgabe: Einlesen einer XML Datei mit 100T Elementen,  die einige Unterelemete besitzt, die Tiefe ist 4, Dateigrösse 60Mb, Java 8.

Zum Performancevergleich wurde mit einem Subset von 350 Elementen gearbeitet.

Test 1: Java, XML, DOM, Xpath, 350 Elemente in Datei

1. Laufzeit pro Element: 20ms
2. Verhältnis XML Parsen/DB Speichern: 25, das XML Verarbeiten verbraucht primär die Zeit
3. Geschätzte Gesamtlaufzeit: 33 min

Test 2: Java, XML, DOM,  Jaxen 1.2 Xpath, 350 Elemente in Datei

1. Laufzeit pro Element: 3ms
2. Verhältnis XML Parsen/DB Speichern: 15, das XML Verarbeiten verbraucht primär die Zeit
3. Geschätzte Gesamtlaufzeit: 5 min
4. Jaxen Xpath ist deutlich schneller als das normale Java Xpath

Beide Tests waren erfolgreich. Jetzt der Test mit voller Datenmenge.

Test 3: Java, XML, DOM,  Jaxen 1.2 Xpath, 100T Elemente in Datei

1. Manueller Abbruch des Test, weil die Laufzeit unglaublich schlecht war.

Test 3: Java, XML, DOM,  Xpath, 100T Elemente in Datei

1. Manueller Abbruch des Test, weil die Laufzeit unglaublich schlecht war.
2. Performance ist aber besser als Jaxen.
3. Bei einer Detailanalyse sieht man das die Laufzeit für die XPath Evaluierung nach oben schnellen, das obwohl ausreichen RAM (XMX) vorhanden ist. Der Schluss daraus ist, das die Auswertung von XPath ausdrücken eine hohe Komplexität hat, es werden scheinbar Listen durchlaufen. Übertragen auf relationale DBs, XPath Evaluierung entsprechen sequential Scans. Java XPath kann also nicht die Element-Adresse im Speicher berechnen, sondern muss sie suchen, indem (mehrere) Listen sequentiell durchlaufen werden.

Zusammenfassung

1. Die Verarbeitung grosser XML Dateien mittels DOM und XPath ist ineffizient. Das gilt wahrscheinlich auch für andere DOM basieret Formate wie JSON.
2. Jaxen XPath ist deutlich schneller als Java XML XPath für kleine und normale DOMs.
3. Lösungen: 
1. Alternativen wäre Streaming XML via SAX oder StAX.
2. Wechsel von XML zu CSV.

XSL CDATA Hack

Eigentlich habe ich XSL schon lange für tot gehalten wegen der schlechten Wartbarkeit und Toolunterstützung. Doch ich probierte mich mal wieder und war erstaunt, wie gut es ging, bis ich auf folgenden Problem stiess: kopieren eines Textknotens von einer XML Datei in eine andere XML Datei, das ist einfach: xsl:copy-of die HTML Formatierungen blieben erhalten, sehr schön. Leider hat das Importprogramm (OpenCMS), welches die neue XML verarbeiten soll ein Problem mit HTML Tags, es möchte dringend alles durch CDATA umschlossen haben, auch das ist einfach: <xsl:output method="xml" indent="yes" cdata-section-elements="content"/>. Jetzt die beiden Sachen kombinieren, fertig. Doch das funktioniert nicht! Bug oder Feature? Das kann ich schwer entscheiden. Da hilft ein alten HTML/JS Hack weiter. Das CDATA wird in Teilstrichs, hier zerlegt xsl:variable und danach zusammengesetzt. Das ganze sieht dann so aus:

Auf diese Weise kann man XSL COPY-OF mit CDATA kombinieren. Auf das CDATA-SECTION-Element kann verzichtet werden.