Java und XSLT: Performanz-Problem

[MarcelloBonventre]

I have a performance issue concerning Java and XSLT: my goal is to transform an xml file (source.xml)
by using a given xsl file (transformation.xsl). As result I would like to get a String object, in which the result
of the transformation (html-code) is in, so that I can display it in a browser. The problem is the long time
it takes for the code below to run through.

xml = new File("C:\\source.xml");
xmlSource = new StreamSource(xml);

xslt = new File("C:\\transformation.xsl");
StreamSource xsltSource = new StreamSource(xslt);

TransformerFactory transFact = TransformerFactory.newInstance();
trans = transFact.newTransformer(xsltSource);

StringWriter stringWriter = new StringWriter();
StreamResult streamResult = new StreamResult(stringWriter);
trans.transform(xmlSource, streamResult);

String output = stringWriter.toString();
stringWriter.close();

Before, I made the same transformation in an xml development environment, named Cooktop
(see http://xmlcooktop.com/). The transformation took about 2 seconds. With the code above in Java it
takes about 20 seconds. :?

Is there a way to make the transformation in Java faster?

Thanks in advance,

Marcello
Oldenburg, Germany
xerxez@gmx.de

*****
*****

The idea to load the code before the result is requested I have implemented. But that surprisingly doesn't bring any nameable improvement in the time it takes the code to run through.

Though I think this is very close to the solution already. Next step I will try to find a way to pre-parse the input document and the transform document. Because I think that especially the large input document takes quite a while to get parsed.

Hatte vielleicht jemand schoneinmal ein ähnliches Problem und kann mir da weiterhelfen?
Kann man ein Eingabe-XML-Dokument vorab parsen und dann die Transformation ausführen? Habe bereits versucht ein DOM aus dem Eingabe-XML-Dokument zu erstellen und die Transformation dann auszuführen. Aber das DOM war anscheinend zu gross, denn ich bekam einen java.lang.OutOfMemoryError.

 

[huckfinn]

1. What kind of transformation tool do you use? I use normally Xalan-J.
2. Does the parser uses SAX or DOM.
(DOM comes with a really big memory footprint and the
memory allocation of the VM needs time.)
3. How large is your file?
If you want to have a look at the too see,
Xalan-J - Explicitly working with SAX in a Servlet enviroment
it can work with SAX 2 in this Example in a Servlet.

Bye Huck

 

[MarcelloBonventre]

1. I use JAXP as API. But I think this uses Xalan-J as XSLT processor.
2. The document doesn't even get parsed in the transformation proccess. As far as I know the transformation gets done through a pluggable transform implementation similar to parsing.
3. The file has 8MB

I'll have a closer look to the link you sent me and try, if that brings an improvement.

THANKS

Marcello

 

[hupfdule]

Wie wärs, wenn ihr in einem deutschen Forum auch deutsch redet?

 

[huckfinn]

Kein Problem ;O) Huck

 

[huckfinn]

Auf jeden Fall wird der Code geparst. Ich denke das Teil, via JAXP oder SAX oder sonst was, muß den Pfadausdruck emitteln um
den Pfad Ausdruck oder Mannigfaltigkeiten davon ( z.B */Name) aufzubauen oder Muster zu erkennen. In meiner Vorstellung hält SAX dabei kein Speichermodell des gesamten Dokumentes sondern nur den oder die Pfadausdrücke die im XLST Skritp gebraucht werden. Wie allerdings dann foreach Strukturen realisiert werden weiß ich nicht genau (Stichwort 2. bzw 3. Durchlauf), denn da müssen Zwischenergebnisse
abgelegt werden (..das finde ich bei XLST so richtig doof da man keine Zustände für einen Patternzustand speichern kann). Also, noch mal ins Blaue. Ich ..wir benutzen bei unseren Projekten Xalan an der Konsole mit richtig großen XML Dateien ..400 Mbyte. Was ich so sehen kann greift sich das System dabei jede Menge Speicher und ist auch schnell. Man müßte das mal testen wie die einzelnen Implementierungen (DOM, SAX ..) sich gegenüber einzelnen Problemstellungen verhalten (Komplexität, Größe ..etc.). Ich habe keine Ahnung aber vielleicht gibt es ja Benchmarks dafür. Das hilft dir sicherlich nicht weiter. Aber was solls. Bis denne Huck