This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: XSLBench - XSLT Processor Benchmark




> -----Original Message-----
> From: owner-xsl-list@mulberrytech.com
> [mailto:owner-xsl-list@mulberrytech.com]On Behalf Of Kay Michael
> Sent: 04 October 2000 20:16
> To: 'xsl-list@mulberrytech.com'
> Subject: RE: XSLBench - XSLT Processor Benchmark
>
>
> > To answer questions I was having over XSLT processor
> > performance I have
> > built a small benchmark of some of the main XSLT processors.
> > You can find the results at,
> >
> > 	http://www.tfi-technology.com/xml/xslbench.html
> >
> Interesting. Some observations:
>
> Saxon definitely benefits greatly from use of JDK 1.3

I have justed posted results using JDK 1.3, where it showed an improvement,
along with setting initial and maximum heap sizes. This does indeed help
many Java based processors significantly, XT appears to have got major
benefit.

>
> You may not have entirely eliminated Java start-up costs from the
> timing; if
> you want to simulate measurement of a continuously-running
> server, it would
> be best to discard the first three runs.

I hadn't thought about this. I will change the test procedure for the next
run.

>
> If I want to maximize my scores on this, I will do something to
> optimize the
> very inefficient use of //X. (This probably wouldn't be a bad idea,
> actually, since I suspect these examples aren't the only ones to
> misuse this
> construct).

I fairly deliberatly just knocked up the style sheets in a quick and dirty
way. I thought this might be a fairer test than spending time tuning
the style sheets. Something which, like you, I suspect happens very little
in practice.

>
> The benchmark will give an enormous boost to any processor that caches
> source document trees in memory, because the same source document is
> processed repeatedly. I decided not to do this in Saxon, because a URI now
> might not give the same content as the same URI half an hour
> previously. But
> it would be better not to expose the benchmark to this possible
> inaccuracy.
>

I hope none of the engines are actually managing to do this in practice. The
intent was clearly that the source document has to be re-read for each
transformation. I will look into this to see if I can make sure that storing
the input tree is not possible.

>
> > P.S. I have a personal interest in one of the processors,
> > Napa, which is noted in the results.
>
> Many of us have found that the last 10% of conformance can cost dearly in
> performance. But good luck to your efforts!
>
> Mike Kay
>

Thanks. It is rather unfortunate that my result appear to be good. I left
them in just to give a bigger picture of what may be available. I don't
imagine this will last as I try to make it more conformant and the other
processors continue to improve.

Kev.

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


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]