RE: Latest XSLTMark benchmark

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

I do have a complication in this area. I normally use a demand loaded DOM so
that the parse and transform stages are actually interwolven, this helps
I/O. I can seperate the stages but the code is optimised for demand loading
and has additional execution costs because of it.

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

Perhaps an alternative is to measure performance on increasingly large input
documents to show the memory scalability of a processor. I do have a
personal interest here in that I also have a paged DOM almost ready to go on
which you can control the memory usage. In this model a kb/kb figure
wouldn't give a useful insight.

Kev.



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