The rewrite experiment only shows that there is a *serious bug*
in the compiler code AND that there is *hope* for much improved
performance of translets testing conditions in template patterns.
'dbonerow' helped focus our attention. There are other tests (eg. decoy)
which seem affected by the same bug. And then there are of course
many stylesheets written by our users :-)
The rewrite is of the form:
if (A && B) { ... } --> if (A) { if (B) { ... }}
If the second version is 300 times faster, then we've got
something interesting going on here :-)
--Jacek
On Thursday 21 February 2002 04:22 am, 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...
> >
>
>
> > > 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...
>
> 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.
>
> </Steven>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
