Phase 2: Daten parsen (Performance)
Sie haben das Speicher-Kapitel gelesen? Die Sache mit den Datenblättern? Gut. Nun drehen wir den Spieß mal um.
Dokumentenart CSV, Datenbank, Excel, Feste Länge
Was den Speicher schont, ist nicht unbedingt das Schnellste. Bauen Sie Ihre Struktur so auf, dass viele einzelne Datenblätter entstehen, vermeiden Sie den kritischen OutOfMemoryError. Das ist immer die bessere Lösung, wenn entweder ein Profil für sich schon sehr große Datenmengen zu verarbeiten hat (oder das zumindest vorkommen kann) oder auch mal mehrere, recht speicherhungrige Profile gleichzeitig laufen könnten.
Aber wie sieht es aus, wenn Sie zwar ein paar tausend Datensätze aus der Datenbank lesen wollen, aber dafür durchaus genug Speicher bereitsteht und Sie den Lauf des Profils auch so steuern können, dass er sich nicht mit anderen Profilen um den Speicher streiten muss? Da ist Ihnen die Geschwindigkeit wohl wichtiger.
In diesem Fall raten wir zu der flachsten, möglichen Struktur. Denn jede Hierarchiestufe im Baum, jeder weitere Knoten, kostet ein wenig Zeit. Nicht viel, aber bei vielen Datensätzen häuft sich was an. Im Idealfall haben Sie dann keinen einzigen Knoten, sondern nur Felder.
Schneller geht es nicht. Und wenn man dann noch ein paar Tricks beim Mappen anwendet, kann man dem Ding einen regelrechten Turbo verpassen. Mehr dazu im Abschnitt zu Phase 3. Aber denken Sie an Ihren Speicher. Bevor Sie riskieren, dass er Ihnen ausgeht, opfern Sie lieber ein kleines bisschen Performance.
Dokumentenart XML
Hier ist es ganz praktisch: Der XML-Parser der Version V3 arbeitet nicht nur platzsparender, sondern auch schneller als der der Version V2. Also sobald mit größeren Datenmengen zu rechnen ist, nutzen Sie einfach Version V3. Und wenn es ganz dick kommt, nehmen Sie Version V4. Dieser neue XML-Parser wurde schon im Speicher-Kapitel erwähnt und es gibt einen eigenen Abschnitt dazu.
Die anderen Formate
Hier lässt sich beim Parsen kaum etwas drehen, aber aufgrund der vergleichsweise geringen Datenmengen (pro Job) ist das auch nicht weiter schlimm. Das Deaktivieren ungenutzter Knoten wurde ja bereits im Speicher-Kapitel für die Dokumentenarten EDIFACT und X12 genannt.