This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Latest XSLTMark benchmark



>
>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]