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]>
> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, February 20, 2002 7:24 PM
> > Subject: XSLT benchmarks: dbonerow
> >
> >
>
> [...]
>
> > >
> > > 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.
Which leads me to think: how hard/expensive would be for an XSLT
processor to 'optimize' algorithmically the XSLT stylesheet?
I mean: fast SQL implementations do this: transform the SQL in a
in-memory structure, then perform some algebraic analysis to obtain
*all* the possible ways to execute he same query (it's hard to formalize
it, but it's doable), then perform some statistical analysis on the
different 'strategies' in order to evaluate the potential algorithmic
cost of each one, then choose the cheapest one and compile that.
Now: XSLTC spends some time creating the translet, I'm pretty sure that
nobody would mind, in a server environment, at least, if XSLTC spent
even a second to find out the best strategy to compile the stylesheet.
Sure, for interpreted execution this might be too much of an overhead,
but for server side compiled execution (given the fact that stylesheets
rarely change in a production environment), the differences that Jacek
show are *huge* and could potentially lead to *incredible* performance
compared to other 'standard' solutions.
I think Scott is right saying that you can't go faster than something
when you are checking for everything in the stylesheet (compliance,
tracing, error cheching and so on) but who said this should be done at
runtime?
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).
Add the ability to 'algorithmically optimize' the sytlesheet before
compilation and I think that we have solved all our issues with XSLT
performance.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
