Re: XSL performance problem

Sebastien Sahuc <ssahuc@xxxxxxxxxxxxxx> wrote:
>... I made benchmark with Servlet using Apache + JServ, meaning
>that at the HTTP request, the servlet is doing the very following
>tasks :
>* Create a new XSLProcessor object;

Is this really necessary? For example, using XT, you can create the
processor (and load the XSL stylesheet into it) only once, and then
repeatedly use it to transform XML documents. If you have a complex fixed
XSL stylesheet this could help a lot.

>* Process the xml document (which was already in memory at servlet
>init);
>* Write the outputstream.

>All overhead du to JVM starting, IO processing are done in advance,
>that's why I'm considering the result a little unhappy.
>But I do understand that none of the processor I used was not
>optimized, so now I'm wondering how much gain can we expect for
>optimized one ?


Java makes it very easy to write well designed, clean, elegant and horribly
inefficient code. For example, my experience from writing a very simple HTML
"text extractor" in Java is that unbelievable amounts of CPU are spent
handling (GC-ing) string objects. We started with parsing <20K/sec and moved
up to >1M/sec, just by using our own "ReuseStr" class instead of Java's
built-in "String" class. I therefore wouldn't be surprised to see a ~x10
improvement in Java based XSL processors once attention is focused on
performance. Of course I'm not actually writing one so that's just a
speculation.

Have fun,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list