RE: Latest XSLTMark benchmark

>   Sounds to me that both are useful metrics. When I run xsltproc
> (the front-end for libxslt), the --timing options shows up:
>    1/ stylesheet parsing time
>    2/ data parsing time
>    3/ transformation duration
>    4/ saving time
> 
>  All 4 are potentially interesting, an implementor of course
> has in mind trying to initiate as much as possible in the first
> phase to get step 2 and 3 be as fast as possible.

Definitely, although we want to stay away from going too far down the
road of profiling -- it is tough to do that right without having access
to the guts of the processors, etc. I think if XSLTMark gets too many
more numbers it will start getting *really* confusing.

>   In this case please measure the total memory footprint too, so that
> people see what is the *actual* amount of memory that a given transform
> will require, not only the heap, but also the code ! Assuming a lot

That's a good point, I think we could only reliably measure overall
footprint anyway. It is difficult with java and other runtime-based
systems, since there is a lot less visibility into their internal
memory management. Presumably memory profiling would have to use really
large documents to force visibility into memory allocation. 

> have different trade-off and a benchmark is only a benchmark, i.e. 
> only one axis of evaluation of a given program or code base (when

It is important to have a fair benchmark that can be used to make
reasonable first-order predictions. Of course, nothing but the actual
application is perfect. We just want to get people's general 
impressions.



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


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