> 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).
Yep. It may be that the interpreter eventually goes away for all purposes
except tools for stylesheet authoring and the like.
> > You know... I wonder why you guys don't spend time on optimizing the
XSL (I
> > know Steven Noels is).
Right on target. In a branch (not on trunk yet) on Xalan interpretive I've
done some work towards this in eliminating redundent path expressions (both
full and partial), also trying to supply API towards rewriting task. From
my experience so far, this will be the #1 tool for great optimization...
things like rewriting certain expressions to xsl:key... lots of things you
can do with index predicates... all sorts of fun things. XSLTC goes a long
way towards solving micro-optimization (loosely termed). DTM/DOMImpl(XSLTC
Source tree version) goes a long way towards solving the source tree issue
(in concept... there's still a lot of work to be done). The next big step
is to really do a lot of work on these rewrites and special internal core
language (like isFirst()). This will really be required for XSLT 2.0/XPath
2.0/XQuery.
> if XSLTC spent
> even a second to find out the best strategy to compile the stylesheet.
No question.
-scott
Stefano Mazzocchi
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
rg> cc: [EMAIL PROTECTED],
Apache Xalan <[EMAIL PROTECTED]>, (bcc:
Scott Boag/Cambridge/IBM)
02/21/2002 05:37 Subject: Re: XSLT benchmarks: dbonerow
AM
Please respond to
cocoon-dev
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
