RE: [xsl] Latest XSLTMark benchmark

Yes, there is indeed a problem. We are working to measure the differences
and issue a speedy update to the tests. I will post when that is available.

> I have just had a look at the Saxon driver and think you are correct. This
> also appear to have been true in the earlier (1_2_1) release as well. It
was
> clearly intended that the loadInput() call should actually load the input
as
> in the other drivers not just open an input stream.

It was there in version 1.1.1, as well. Everyone, including Michael Kay,
missed
it -- the disagreement between the documentation, the code in the other
drivers,
and the Saxon driver. The intention (which may not be practical) was always
to
measure just the XSLT transformation.

> 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").

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


\\ Eugene Kuznetsov
\\ eugene@xxxxxxxxxxxxx
\\ DataPower Technology, Inc.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list