cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: xslt and jxtg performance
Date Tue, 31 May 2005 19:28:03 GMT
BURGHARD √Čric wrote:
> Daniel Fagerstrom wrote:
>>If you want to help making JXTG faster you need to submit more
>>information. We need examples that reproduce this behaviour with the
>>JXTG template and the corresponding XSLT. We also need to know exactly
>>what version of 2.2 you used. How did you measure preformance? Profiling
>>info is rather helpful
> I apologize.

No problem, these performance issues is always a little bit touchy ;)

> I just wanted to emphasize the fact that a partially automated
> transformation produce a code that seems to be more efficient than its
> original. nothing more, but i would really like to give you something more
> in order to improve jxtg. I just made some quick & dirty comparison based
> on access info (the log category). I use apparently the old jxtg with
> macros so this is perhaps the reason.

The work Leszek and I have done is mainly a refactoring that probably 
shouldn't affect performance in any direction, except for the small bug 
that I described in my previous post.

>>JXTG compiles the script to a sequence of SAX events and also compiles
>>the expressions. So during execution nothing complicated is supposed to
>>happen, except for what is done internally in the expressions. So there
>>is really no reason that it should be any slower than saxon8. But of
>>course there can be small things in specific instructions or in the
>>execution engine that slows things down. When one have got the basic
>>algoritms right (which I think we have), optimization is much about
>>small details.
> Have you some benchmarks on the xpath evaluator ? We use quite a lot of
> xpath processing on a several ko dom (given as a param from flow). That's
> perhaps a good reason why saxon8 handle this quicker (expressions are
> indeed the same between the stylesheets).

That sounds like a reasonable explanation. There can AFAIU be quite 
large performance differences between different XPath evaluators. And as 
being efficient on DOM not is the main focus for JXTG, it is probably 
far from the most performant. While Saxon8 probably is one of the 
better. Profiling data would still be interesting for seeing that this 
really is the problem.

IIRC Saxon's XPath processor can be used standalone and there is also 
Jaxen. If anyone have the itch it wouldn't be that complicated to write 
a small wrapper so that the XPath processor implements 
o.a.c.components.expression.Expression, and then it could be plugged in 
into JXTG.

OTH, if one is interested in processing DOM, XSLT or XQuery are probably 
the best chocices.


View raw message