Subject: RE: [xsl] Latest XSLTMark benchmark From: "Kevin Jones" <kjouk@xxxxxxxxxxx> Date: Sun, 1 Apr 2001 20:29:16 +0100 |
> >> of variance is how a processor saves the output, some of the tests can >> become I/O bound so it can make a big difference. The MS driver has lots >of >> output handling code presumably for performance reasons. > >Turns out that output is not very significant, but we did try to >exclude it. >It became apparent that the clock resolution is not sufficient to produce >accurate results, so we opted for leaving it in. The MS driver does *NOT* >do anything special for performance reasons, the COM object was only needed >to make it output UTF-8. (If it put out UTF-16, it would give it a >huge advantage in "bytes/sec"). That's good to know. It just looked like a hell of a lot of code to write the output. The clock resolution is only an issue given the relatively small sample size for some of the tests. To give Java processors a chance to warm up I think you should really do some un-timed runs followed by some timed ones where runs is significantly >10. On some stylesheets, output costs is the dominant factor. Exactly which is going to depend on the speed of your disks on the test machines but I regularly see differences of 30% between runs if I swap between saving the output to a file and just throwing it away. >> >could legitimately cache the results of parsing the document in memory, >> I don't think this is an issue with XSLTMark as its currently written since >> the driver is (normally??) requested to load the XSL and XML before the >> timing starts. > Right, that was the whole point. Also, not all trees come from documents and > there are already parser speed measurements out there. I don't think that document loading is a completely un-interesteing issue. While it may be true that parser speed is fairly well understood much of the document loading cost is in how the XSLT processor creates an internal tree (if it does) rather than what the parser does. I routinely see tree construction from SAX events as been equal or greater to the parser cost of generating SAX events. Kev. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] illegal xhtml attributes?, Michael Kay | Thread | RE: [xsl] Latest XSLTMark benchmark, Eugene Kuznetsov |
Re: [xsl] illegal xhtml attributes?, cutlass | Date | RE: [xsl] Latest XSLTMark benchmark, Eugene Kuznetsov |
Month |