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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format