[XSL-LIST Mailing List Archive Home]
RE: [xsl] Latest XSLTMark benchmark
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
>> output handling code presumably for performance reasons.
>Turns out that output is not very significant, but we did try to
>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 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
>> 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
> 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.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list