cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Koberg" <...@koberg.com>
Subject Re: XSLT benchmarks: dbonerow
Date Thu, 21 Feb 2002 13:19:26 GMT

----- Original Message -----
>From: "Stefano Mazzocchi" <stefano@apache.org>

> >Steven Noels wrote:
> >
> > > Robert Koberg wrote:
> > >
> > > You know... I wonder why you guys don't spend time on optimizing the
XSL (I
> > > know Steven Noels is). This is most probably the bottleneck you are
> > > experiencing?? You guys are taking the path away from general
adoption...
> > >
> > >
> > > ----- Original Message -----
> > > From: "Jacek Ambroziak" <jacek_ambroziak@yahoo.com>
> >
> > [...]
> >
> > > >
> > > > I have rewritten XSL as follows:
> > > >
> > > > <xsl:template match="row[id = '0432']">
> > > > stuff
> > > > </xsl:template>
> > > >
> > > > to
> > > >
> > > > <xsl:template match="row">
> > > >   <xsl:if test="id = '0432'">
> > > >     stuff
> > > >   </xsl:if>
> > > > </xsl:template>
> > > >
> >
> > Well, I fully trust the judgment of Jacek here...

The above should use xsl:key


> >
> > Depending on your favorite brand of XSLT engine, I'm quite sure
different
> > optimalizations will be applied upon stylesheet execution. XSLTC has
been
> > available long enough inside Xalan to finally start using it, or at
least making
> > its usage possible & optional. It will be up to the classloading gurus
however
> > to tackle this one.
> >
> > I must say I'm quite stumped finding out how you should
rewrite/optimalize your
> > stylesheet in order to fully utilize XSLTC: predicates in XSLT Patterns
seem
> > like a different beast to me than an xsl:if construct, and one can not
be
> > trusted to keep this kind of optimalization in mind while authoring a
> > stylesheet.
> >
> > I'm quite sure this is not the intended behaviour of XSLTC, hopefully
Jacek
> > finds time to correct XSLTC on this.
> >
> > Anyway, another discussion which shows me XSLT has not yet proven to be
a highly
> > optimizable language, even though it has been created with
side-effect-freeness
> > in mind. And finally, something I learnt from Berin and other wise men
on this
> > list: one must not start with sourcecode optimalization targeting a
specific
> > runtime environment unless *all* other possibilities are exhausted. And
XSLTC
> > seems like a good possibility for the 'bad' (really?) XSLT performance
in
> > Cocoon.

I don't agree. Most people come to XSL thinking it is like JSP/ASP/etc. They
write XSLs that conforms to that thinking and it leads to slow/ugly XSLT.

>
> Which leads me to think: how hard/expensive would be for an XSLT
> processor to 'optimize' algorithmically the XSLT stylesheet?

I know Saxon does this. I usually find that Saxon is the best/fastest
(conformant) when the XSL is as clean as possible. I am not talking about
XSLTC because I think in terms of development of the site rather than
deployment, but I assume XSLTC could only benefit from an optimized XSL
(ASSumption).

<snip/>
>
> IMO, the best think would be to have an XSLT interpreter for your
> development cycles (where compliance and low latency are most important)
> and an XSLT compiler for production release (where runtime performance
> and scalability are the issues and low latency is not).

I like this. This should be codified into How to Use Cocoon or even into the
Way you have-to use cocoon.

>
> Add the ability to 'algorithmically optimize' the sytlesheet before
> compilation and I think that we have solved all our issues with XSLT
> performance.
>

best,
-Rob



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message