This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Latest XSLTMark benchmark
- To: <mhkay at iclway dot co dot uk>, <xsl-list at lists dot mulberrytech dot com>, <kjouk at yahoo dot co dot uk>
- Subject: RE: [xsl] Latest XSLTMark benchmark
- From: "Eugene Kuznetsov" <eugene at datapower dot com>
- Date: Mon, 2 Apr 2001 09:16:19 -0400
- Cc: "'Xsltmark at Datapower dot Com'" <xsltmark at datapower dot com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Everyone: the XSLTMark 2.0 results page has been updated to explain the
error, and we have also contacted xml.com.
Forward to what should be done:
> I do think that the benchmark should be measuring parsing plus
> transformation plus serialization, because that is the most typical usage
> scenario, and because if you don't measure that, a processor that
> optimizes
> parsing or serialization based on knowledge of the stylesheet
> gets no credit
> for it.
These are persuasive points, especially when it comes to some of the
next-generation optimizations. Do any other XSLT implementors have an
opinion on "parse+transform" vs. "transform only"?
Kevin also correctly points out the usefulness of measuring memory
consumption. This is even trickier to do right (although we have done some
internal tests), but would be a very useful metric. Presumably one would
express it as "kilobyte per kilobyte", where the first kilobyte is input
size and the second one is heap size delta -- measuring "memory efficiency"
of a processor.
\\ Eugene Kuznetsov
\\ eugene@datapower.com
\\ DataPower Technology, Inc.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list