Good suggestion. Thanks.
-scott
"Lewis, Andrew J"
<[EMAIL PROTECTED] To:
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
c.nasa.gov> cc:
[EMAIL PROTECTED], Apache Xalan <[EMAIL PROTECTED]>, (bcc:
Scott Boag/Cambridge/IBM)
02/21/2002 11:32 AM Subject: RE: XSLT benchmarks:
dbonerow
Please respond to
cocoon-dev
What might help imeensely was an option to output the execution plan for
the
stylesheet - similar to what you can get from a database. Even if there
isn't extensive optimization taking place in the interpreter, at least it
might show you where your "hotspots" are for stylesheet tuning.
> ----------
> From: [EMAIL PROTECTED][SMTP:[EMAIL PROTECTED]]
> Reply To: [EMAIL PROTECTED]
> Sent: Thursday, February 21, 2002 11:18 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; Apache Xalan
> Subject: Re: XSLT benchmarks: dbonerow
>
>
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
