Die Diskussion ist so alt wie die Programmierung selbst: Welcher Compiler beziehungsweise Interpreter ist der schnellste im ganzen Land? Was für Assembler, C/C++ und andere Programmiersprache galt, gilt auch für XSLT: hier ist es der Prozessor, der entscheidet.

Interpretationssache
Zu groß sind die Unterschiede, vor allem in der Performance. Ein Prozessor optimiert den XSLT-Code, der andere nicht, und ein weiterer kompiliert ihn gar in ausführbaren Maschinen- oder alternativ in Bytecode.

Ein Beispiel für die erste Kategorie ist der mächtige XSLT-Prozessor Saxon von Saxonica. Dessen Gründer und Geschäftsführer ist Michael Kay, Editor von XSLT 2.0. Von daher ist es keine Überraschung, dass Saxon, das sowohl in einer Java- als auch in einer .NET-Variante existiert, "XSLT 2.0 ready" ist.

Saxon optimiert, wo es nur geht, und nimmt es dabei sehr genau. Ein Beispiel:

<xsl:sequence select="for  in 1 to  return math:random()" />

Die Funktion random stammt übrigens nicht von Saxon oder aus XSLT 2.0, sondern aus dem EXSLT-Projekt, und liefert eine Zufallszahl. Demnach sollte das gezeigte Codefragment eine Liste von Zufallszahlen liefern, die – nachdem sie zufällig generiert wurden – sich mit hoher Wahrscheinlichkeit jeweils voneinander unterscheiden. Doch nicht so bei Saxon: dort besteht die Liste aus einer einzigen, sich wiederholenden Zufallszahl.

Das ist kein Bug, sondern ein Feature: Der Saxon-Prozessor erkennt, dass der Schleifenrumpf (return math:random()) keinen Bezug zur Schleifenvariable () besitzt. Für die Optimierung berechnet der Prozessor den Wert der random-Funktion einmalig und produziert hieraus die gewünschte Anzahl an Kopien. Dieses Vorgehen ist zulässig, weil Funktionen im mathematischen Sinn keinen Zustand besitzen, also für die gleiche Eingabe jeweils die gleiche Ausgabe liefern.

Die Lösung in diesem Fall lautet übrigens: random:random-sequence – ebenfalls eine Erweiterungsfunktion aus dem EXSLT-Projekt.

Gerade in der Zeit
Einen anderen Weg geht .NET ab der Version 2.0: es kompiliert das XSLT-Stylesheet in den Intermediate-Language-Code (eine Form von Bytecode). Genauer: die XslCompiledTransform-Klasse löst die XslTransform-Klasse ab. Im Unterschied zu dieser lädt deren Load-Methode das Stylesheet nicht nur in den Speicher, sondern generiert hieraus eine temporäre Klasse. Deren Code setzt die Anweisungen im Stylesheet um und operiert direkt auf dem Eingabedokument.

Dass die Kompilierung von XSLT in einen Zwischencode keineswegs ein zeitfressender Umweg ist, zeigt ein Vergleich zwischen dem alten (.NET 1.0) und dem neuen (.NET 2.0) XSLT-Prozessor von .NET:
 

Je nach Anwendungsszenario ist die Variante mit der Kompilierung um ein Zwei- bis Siebenfaches schneller als die ohne. Das Kompilieren kostet natürlich Rechenzeit, doch die fällt kaum ins Gewicht, wenn das Eingabedokument groß und die Berechnung aufwendig ist oder das Stylesheet mehrfach Anwendung findet.

Bei dem Beispiel, aus dem die Messdaten gewonnen wurden, treffen zwei Kriterien zu: das Dokument besteht aus 25 000 Elementen, und je nach Anwendungsfall werden alle Elemente für die Ausgabe genutzt (Transform) oder es wird nur nach bestimmten Elementen gesucht (Search).

Die halbe Miete
Eine gute Vorbereitung ist die halbe Miete. Auf XSLT-Prozessoren angewandt: wer vorkompiliert, hat den halben Rechenaufwand schon geleistet (oder zumindest einen Teil davon). Ein Stylesheet erst zur Laufzeit zu übersetzen, wie es die XslCompiledTransform-Klasse implementiert, macht nur dann Sinn, wenn das Stylesheet auch erst während der Programmausführung erzeugt wird. Und das ist wohl eher selten der Fall.

Stattdessen ließe sich das Stylesheet bereits zum Zeitpunkt der Programmerstellung kompilieren. Genau diesen Weg geht Microsoft mit dem XSLTC-Werkzeug, das mit der kommenden Version von Visual Studio (Codename "Orcas") Anfang 2008 verfügbar sein wird. Es generiert aus dem Eingabedokument im XSLT-Format eine ausführbare Programmbibliothek als .NET-Assembly.

Einen Schritt weiter geht das Plug-in IronXslt für Visual Studio: es macht aus einem XSLT-Stylesheet ein herkömmliches Quellcodemodul, welches bei der Kompilierung der Anwendung genauso wie etwa eine C#-Datei in eine .NET-Klasse übersetzt wird.

Die Idee, Stylesheets in einen binären Zwischencode zu übersetzen, der weitaus effizienter ausgeführt werden kann als der textbasierte XSLT-Code, ist  keineswegs auf .NET beschränkt. Auch die Java-Welt kennt einen solchen Compiler: die Apache-Foundation stellt im Rahmen des Xalan-Projekts das Werkzeug XSLTC bereit, um XSLT-Stylesheets in so genannte "Translets" zu kompilieren. Ein Translet ist ein Satz von Java-Klassen, die direkt auf die XML-Eingabedokumente angewendet werden können.

History repeating
Die XML-Sprache XSLT folgt dem Verlauf vieler moderner Programmiersprachen: zunächst als reine Interpretersprache gedacht, gab es bald die ersten Just-in-Time-Compiler. Nun kommt die Zeit der Compiler, und bald sind diese auch in die gängigen Entwicklungsumgebungen integriert. Dann ist XSLT eine Programmiersprache unter vielen.

Martin Szugat ist sich sicher: XSLT gehört schon jetzt zum Grundrepertoire eines Entwicklers, so wie SQL oder HTML. Über XSLT im Speziellen und XML im Allgemeinen berichtet der langjährige Fachautor und Softwareberater auch im dot.net magazin sowie auf www.aboutxml.de.