You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by BURGHARD Éric <er...@systheo.com> on 2005/05/31 18:31:56 UTC
xslt and jxtg performance
just for information,
i've achieved some template migration from jxtg (2.2-dev) to
xslt 2.0 (saxon8) and record a 7 to 10 factor speed increase on the same
pages (cache desactivated).
the templates (jx+jpath) were transformed (for the biggest part) by a simple
xslt 2.0 stylesheet. Common constructions and expressions are almost
trivial to convert to xslt 2.0 + xpath 2.0. jx:import is converted to
xi:include (handled by xerces) and jx:macro to xsl:template (sometimes
manually rewritten to xsl:function). Only a few manual modifications were
necessary to make things work (jexl java tricks -> clean xsl). We didn't
use fancy things at all.
flow and pipeline are almost the same (sendpage params to url params, and
dom param to generator inside pipeline).
Some of our pages are still in jxtg. We need to drive transformation based
on cform model. jxtg + cform macros are really usefull here, but i'm really
frighten by the poor performance we have on quite a big model + template
(several seconds: who's guilty ?). I'm quite convinced that cform generator
+ xslt 2.0 library (functions and templates) could make things as easy as
they are with jx + cform macros.
Anybody went through this way before ?
Re: xslt and jxtg performance
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Peter Hunsberger wrote:
> On 5/31/05, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>
>>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 ;)
>
> It should probably be pointed out that other people have found that
> the latest releases of Saxon 8 are significantly faster than previous
> versions of Saxon (and it was already faster than many processors).
> We've seen much better preformance for some of our stuff. So, much of
> this might be a Saxon issue and not JXTG/Cocoon issue...
Éric's scripts made heavy use of JXPath on DOM trees, so until I'm
proved wrong with hard profiling data, I will assume that it is a JXPath
issue rather than an JXTG/Cocoon issue ;)
To be able to do know if and in that case where e.g. JXTG have
performance problems we need to set up benchmark scripts and profiling
as part of the distro.
/Daniel
Re: xslt and jxtg performance
Posted by Peter Hunsberger <pe...@gmail.com>.
On 5/31/05, Daniel Fagerstrom <da...@nada.kth.se> wrote:
> 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 ;)
>
It should probably be pointed out that other people have found that
the latest releases of Saxon 8 are significantly faster than previous
versions of Saxon (and it was already faster than many processors).
We've seen much better preformance for some of our stuff. So, much of
this might be a Saxon issue and not JXTG/Cocoon issue...
<snip/>
--
Peter Hunsberger
Re: xslt and jxtg performance
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: xslt and jxtg performance
Posted by BURGHARD Éric <er...@systheo.com>.
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. 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.
> 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).
> Anyway, without more data about what happens, there is not much we can do.
>
> /Daniel
Re: xslt and jxtg performance
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
BURGHARD Éric wrote:
> just for information,
>
> i've achieved some template migration from jxtg (2.2-dev) to
> xslt 2.0 (saxon8) and record a 7 to 10 factor speed increase on the same
> pages (cache desactivated).
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.
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.
Anyway, without more data about what happens, there is not much we can do.
/Daniel
Re: xslt and jxtg performance
Posted by Reinhard Poetz <re...@apache.org>.
BURGHARD Éric wrote:
> just for information,
>
> i've achieved some template migration from jxtg (2.2-dev) to
> xslt 2.0 (saxon8) and record a 7 to 10 factor speed increase on the same
> pages (cache desactivated).
>
> the templates (jx+jpath) were transformed (for the biggest part) by a simple
> xslt 2.0 stylesheet. Common constructions and expressions are almost
> trivial to convert to xslt 2.0 + xpath 2.0. jx:import is converted to
> xi:include (handled by xerces) and jx:macro to xsl:template (sometimes
> manually rewritten to xsl:function). Only a few manual modifications were
> necessary to make things work (jexl java tricks -> clean xsl). We didn't
> use fancy things at all.
>
> flow and pipeline are almost the same (sendpage params to url params, and
> dom param to generator inside pipeline).
>
> Some of our pages are still in jxtg. We need to drive transformation based
> on cform model. jxtg + cform macros are really usefull here, but i'm really
> frighten by the poor performance we have on quite a big model + template
> (several seconds: who's guilty ?).
macros in jxtemplate caused some big performance problems
(http://marc.theaimsgroup.com/?t=111625859100003&r=1&w=2). Thanks to Daniel the
problem has been fixed in the template block (*trunk-only*).
> I'm quite convinced that cform generator
> + xslt 2.0 library (functions and templates) could make things as easy as
> they are with jx + cform macros.
>
> Anybody went through this way before ?
Not that I know of. If you go this way, I would be interested in benchmarks
comparing the different alternatives.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: xslt and jxtg performance
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
BURGHARD Éric wrote:
>>An important point: which JXTG are you using? The original one, or the
>>new implementation in trunk?
>
> It's a quite old now 2.2-dev, so i think this is not the refactored one. I
> will try to update to current trunk, and retest.
>
> We use macros and sometime evalBody (i've already heard about macros
> performance problem and happy to know that it's fixed now), so perhaps this
> is the reason of the poor performance.
There are still much work left to do on macros. The problem we fixed was
a tiny bug/missfeature that killed performance when calling expression
that has void as return type. This happens a lot in CForms macros.
/Daniel
Re: xslt and jxtg performance
Posted by BURGHARD Éric <er...@systheo.com>.
>
> An important point: which JXTG are you using? The original one, or the
> new implementation in trunk?
It's a quite old now 2.2-dev, so i think this is not the refactored one. I
will try to update to current trunk, and retest.
We use macros and sometime evalBody (i've already heard about macros
performance problem and happy to know that it's fixed now), so perhaps this
is the reason of the poor performance.
regards
Re: xslt and jxtg performance
Posted by Sylvain Wallez <sy...@apache.org>.
BURGHARD Éric wrote:
>just for information,
>
>i've achieved some template migration from jxtg (2.2-dev) to
>xslt 2.0 (saxon8) and record a 7 to 10 factor speed increase on the same
>pages (cache desactivated).
>
>
An important point: which JXTG are you using? The original one, or the
new implementation in trunk?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director