----- Original Message ----- >From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
> >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" <[EMAIL PROTECTED]> > > > > [...] > > > > > > > > > > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
