Channel SOA

XSLT ist nicht eben ein Renner, wenn es um die Verarbeitungsgeschwindigkeit geht. Das hat viele Entwickler davon abgehalten, es in Serveranwendungen einzusetzen, um beispielsweise XML-Daten in HTML-Seiten zu transformieren.

Hartnäckige Vorurteile
Das Argument der Langsamkeit trifft aber weder in der Version 1.0 noch in der Version 2.0 zu, zumindest nicht im Allgemeinen. Denn im Speziellen hängt es von dem jeweiligen XSLT-Prozessor, dem XSLT-Stylesheet und natürlich dem zu verarbeitenden XML-Dokument ab.

Die Verarbeitung eines 1 GB großen Dokuments ist unabhängig vom Format zeitaufwendig, so viel ist klar. Klar ist auch, dass XML-Formate zum Größenwahn neigen. Geeignete Gegenmaßnahmen sind bekannt und können zumindest die Übertragung der XML-Daten und das Parsen derselben beschleunigen.

Selbstverständlich hängt die Verarbeitungsgeschwindigkeit auch davon ab, wie das Stylesheet programmiert ist. Eine Liste immer wieder sequenziell nach bestimmten Werten zu durchsuchen, ist langsam, egal in welcher Programmiersprache. Besser ist die Verwendung einer Hashtable. In XSLT heißt das Zauberwort xsl:key und findet viel zu selten Anwendung.

Der Schlüssel zum Erfolg
Stellen Sie sich ein XML-Dokument vor: es enthält eine Liste von Produkten, denen jeweils ein eindeutiger Bezeichner und ein beschreibender Name zugeordnet sind. Eine zweite Liste im selben Dokument listet die Preise auf, die je nach Land unterschiedlich sind. Ein XSLT-Stylesheet soll einen Produktkatalog für Deutschland erstellen, der neben dem Namen des Produkts auch dessen Preis enthält. Das Stylesheet muss hierfür eine der beiden Listen durchlaufen und sich das jeweils passende Element aus der zweiten Liste besorgen. Hierzu nutzt es den eindeutigen Bezeichner, der als Bindeglied zwischen beiden Listen fungiert.

Bei einem Katalog mit einer Million Einträgen kann diese Aufgabe auf einem Standard-PC durchaus mehrere Minuten Rechenzeit beanspruchen. Der Flaschenhals ist schnell entdeckt: das Durchsuchen der zweiten Liste nach dem jeweils passenden Element (Bezeichner) kostet unnötig viel Zeit, denn der XSLT-Prozessor durchläuft die Liste stets von Anfang zum Ende hin und untersucht dabei Element für Element.

Die Lösung ist einfach:

<xsl:key name="products" match="product" use="@id" />

Dieser Befehl zu Beginn der XSLT-Datei erzeugt eine interne (Hash-)Tabelle namens products, die product-Elemente unter dem Wert ihres id-Attributes indiziert. Auch die Nutzung dieser Tabelle ist denkbar einfach:

<xsl:value-of select="key('products',
current()/@product-id)/@name"/>

Die Funktion key liefert für einen gegebenen Schlüsselwert (im zweiten Parameter) das dazu passende Element aus der jeweiligen Tabelle (deren Name steht im ersten Parameter).

Durch die Verwendung dieses einfachen Mechanismus reduziert sich die Verarbeitungsdauer auf wenige Sekunden. Umso größer die Tabelle ist und umso häufiger sie genutzt wird, umso größer fällt auch der Performancegewinn durch die key-Funktion aus.

Relativismus
Umgekehrt bedeutet dies: bei kleinen Dokumenten und wenig komplexen Stylesheets bringt die Verwendung des key-Elements wenig. Sie kann sogar kontraproduktiv sein – wenn der Aufbau der Tabelle mehr Zeit beansprucht als die lineare Suche.

Bei Webanwendungen gelten zudem verschärfte Regeln: ob eine Transformation in wenigen Sekunden oder in mehreren Minuten stattfindet, spielt schon fast keine Rolle mehr. Der Benutzer erwartet in Bruchteilen von Sekunden eine Antwort. Große XML-Dokumente sind hier also ohnehin tabu. Dementsprechend mager fällt der Performancegewinn durch die geschickte Programmierung des Stylesheets aus.

Als Zeitfresser entpuppt sich vielmehr die Interpretation des Stylesheets, die im schlechtesten Fall bei jeder Anfrage auf das Neue erfolgt. Lösungen sind: die XSLT-Ausgabe in einem Cache vorhalten und/oder das Stylesheet in eine direkt ausführbare Form überführen, sprich kompilieren.

Rückblick und Ausblick
Optimieren und Kompilieren, das sind die beiden Strategien, die zu einem schnelleren XSLT verhelfen. Entscheidend ist also vor allem der XSLT-Prozessor. Um ihn geht es in zweiter Folge zum Thema XSLT und Performance.

Martin Szugat nutzt XSLT oft und gerne, nicht weil es schnell ist, aber weil sich damit schnell Ergebnisse produzieren lassen. Neben XSLT beschäftigt sich der Berater und Fachautor auch mit XQuery, XML Schema und XML in .NET. Zu XML in .NET hält er auch Workshops, unter anderem auf der BASTA und bei der Entwickler-Akademie.