[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Updated Benchmark Available

Subject: RE: Updated Benchmark Available
From: "Kevin Jones" <kjouk@xxxxxxxxxxx>
Date: Fri, 6 Oct 2000 19:04:46 +0100
kevin email yahoo.com 2000
>
> The benchmark results look interesting, but what do they really
> demonstrate?
>
> At my opinion, with the longest test running not more than 0.6 seconds,
> these results compare the time which XSLT engines need to warm-up and to
> cleanup, rather than the time they need to perform their main job.
> Furthermore, the warm-up and the cleanup time depends on the run-time
> system of the underlying platform (JVM, C++ RTL etc.), not on the
> quality of the XSLT processor itself.
>

There is some truth in this for the Java stuff. Sebastien Sahuc has pointed
out that with just 10 runs, Hotspot is not getting time to find the
'hotspots'.
I have updated the tests to perform 100 runs for warm up and 100 for timing.
In practice this has helped the Java engines on Test1 but made little to no
difference on Test 2 & 3.

> From the practical point of view, the result of this benchmark could be
> formulated as follows:
>
> "... All XSLT processors (except those crashed) demonstrated a good
> performance ..." (0.6 sec is a good response time - isn't it?)
>

While its true that all the processors demonstrated good performance times
there are significant differences between them. My main interest is in
using XSLT in high-transaction web sites. In this environment a bad
choice of processor can cost you 8 times more transformation time. In other
environments you may not care at all about this in which case the
benchmark is irrelevant to you.

> I also could not understand why the issue whether the XSLT processor is
> using the "pre-parsed" style sheets is so important. Some processors do
> it, some don't, but the efficiency of this feature in fact depends on
> the processor architecture and on the way how this pre-parsing is
> integrated with the other processor components.
>

This really becomes a issue when you are performing many transformations
using the same style sheet. It may be possible to write a quick engine
that does not use any form of pre-parsed style sheet but my guess would
be that it would perform poorly on this particular benchmark.


> Kind regards
>
> Alexey Gokhberg
> Developer of Unicorn XSLT Processor
> http://www.unicorn-enterprises.com/uxsl_1_02_15.zip
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Regards,
Kev.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.