RE: Latest XSLTMark benchmark

>> Perhaps an alternative is to measure performance on increasingly
>> large input documents to show the memory scalability of a
>> processor.
>
>That was my thinking, but I am not sure why you say that kb/kb
>figure wouldn't work in that case. I guess you might get greater
>than 100% efficiency, but that is somewhat true -- at the cost of
>additional cpu resources.

That's the difficulty, if we are going to start seeing more advanced DOM
implementations around. For example, what happens if you base an XSLT
processor directly on a database. You could just say the figures don't make
any sense but more likely it depends a lot on the configuration of the DOM
as to what speed/memory trade off you get. Maybe this is just asking too
much of one benchmark to cover all these cases.

>
>(BTW, are we ever going to get to include Napa in our benchmark
>result releases? Your site implies you have a driver...)
>

Hope so. There is a driver that I have been using myself but I haven't
wanted to promote Napa too much recently while I get it to a 1.0 release and
stabilise the implementation model.

Kev.



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