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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format