[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XSLBench - XSLT Processor Benchmark
> -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Kay Michael > Sent: 04 October 2000 20:16 > To: 'xsl-list@xxxxxxxxxxxxxxxx' > Subject: RE: XSLBench - XSLT Processor Benchmark > > > > To answer questions I was having over XSLT processor > > performance I have > > built a small benchmark of some of the main XSLT processors. > > You can find the results at, > > > > http://www.tfi-technology.com/xml/xslbench.html > > > Interesting. Some observations: > > Saxon definitely benefits greatly from use of JDK 1.3 I have justed posted results using JDK 1.3, where it showed an improvement, along with setting initial and maximum heap sizes. This does indeed help many Java based processors significantly, XT appears to have got major benefit. > > You may not have entirely eliminated Java start-up costs from the > timing; if > you want to simulate measurement of a continuously-running > server, it would > be best to discard the first three runs. I hadn't thought about this. I will change the test procedure for the next run. > > If I want to maximize my scores on this, I will do something to > optimize the > very inefficient use of //X. (This probably wouldn't be a bad idea, > actually, since I suspect these examples aren't the only ones to > misuse this > construct). I fairly deliberatly just knocked up the style sheets in a quick and dirty way. I thought this might be a fairer test than spending time tuning the style sheets. Something which, like you, I suspect happens very little in practice. > > The benchmark will give an enormous boost to any processor that caches > source document trees in memory, because the same source document is > processed repeatedly. I decided not to do this in Saxon, because a URI now > might not give the same content as the same URI half an hour > previously. But > it would be better not to expose the benchmark to this possible > inaccuracy. > I hope none of the engines are actually managing to do this in practice. The intent was clearly that the source document has to be re-read for each transformation. I will look into this to see if I can make sure that storing the input tree is not possible. > > > P.S. I have a personal interest in one of the processors, > > Napa, which is noted in the results. > > Many of us have found that the last 10% of conformance can cost dearly in > performance. But good luck to your efforts! > > Mike Kay > Thanks. It is rather unfortunate that my result appear to be good. I left them in just to give a bigger picture of what may be available. I don't imagine this will last as I try to make it more conformant and the other processors continue to improve. Kev. > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com 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
|