RE: Latest XSLTMark benchmark

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

Good idea... So good that the current version already does that!
Here is what XSLTMark 2.0 prints out when running with XT.

dummy initialization run:
xslbench3:          xslbench3.xsl       xslbenchdream.xml   ... done in
644ms.

> The clock resolution is only an issue given the relatively small
> sample size

It's an issue if one tries to measure each iteration separately. It is
not an issue now, because XSLTMark usually measures many 100's, if not
1000's of milliseconds at a time -- but it is an issue if one tries to
time the output separately or to time the parsing separately on every
run.

> That's good to know. It just looked like a hell of a lot of code to write
> the output.

XSLTMark has over 6,000 lines of code, which is kind of stunning given
the simplicity of its purpose. That does not include any of the XSL
or compliance references, which also require constant review and
maintenance.

> I don't think that document loading is a completely un-interesteing issue.

Neither do I, it was just a matter of what we wanted to focus on first.


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



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