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
http://marc.theaimsgroup.com/?t=111625859100003&r=1&w=2.
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.
/Daniel
