cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott_b...@us.ibm.com
Subject RE: XSLT benchmarks: dbonerow
Date Thu, 21 Feb 2002 16:34:17 GMT

Good suggestion.  Thanks.

-scott




                                                                                         
                                                  
                      "Lewis, Andrew  J"                                                 
                                                  
                      <Andrew.Lewis@jbosc.ks        To:       "'cocoon-dev@xml.apache.org'"
<cocoon-dev@xml.apache.org>                     
                      c.nasa.gov>                   cc:       jacek_ambroziak@yahoo.com,
Apache Xalan <xalan-dev@xml.apache.org>, (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:            scott_boag@us.ibm.com[SMTP:scott_boag@us.ibm.com]
> Reply To:              cocoon-dev@xml.apache.org
> Sent:            Thursday, February 21, 2002 11:18 AM
> To:              cocoon-dev@xml.apache.org
> Cc:              jacek_ambroziak@yahoo.com; 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
>
>                       <stefano@apache.o        To:
> cocoon-dev@xml.apache.org
>
>                       rg>                      cc:
> jacek_ambroziak@yahoo.com, Apache Xalan <xalan-dev@xml.apache.org>, (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" <jacek_ambroziak@yahoo.com>
> > > To: <xalan-dev@xml.apache.org>; <cocoon-dev@xml.apache.org>
> > > Cc: <stefano@apache.org>
> > > 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.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org







---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message