Re: Stylesheet optimisation

Subject: Re: Stylesheet optimisation
From: Ray Cromwell <ray@xxxxxxxxxxxxx>
Date: Fri, 3 Dec 1999 17:26:29 -0500 (EST)
> 
> > Ouups, forgot the links to java lobby post :
> >
> http://www.javalobby.org/servlet/News?action=displayStories&xsl=comment.xsl&;
> format=full&id=510100000000125
> 
> Interesting article. Having experimented with various ways of avoiding
> building the full tree, I'm sure many interesting transformations can be
> done this way, but the language to achieve them won't be XSLT. XSLT gives
> you direct read access to the input document and append access to the output

I was the original author of that post. I don't understand what you
mean by saying that the "language to achieve them won't be XSLT" That's
like saying "there are many ways of inlined polymorphic dispatch,
but the language to achieve them won't be Java" (JIT v HotSpot) or
"there are many ways of optimizing a join, but the language
won't be SQL"

My point is that for web sites that are transforming simple DTDs
like database result sets, there exists a subset of XSLT/XPath that
can be efficiently processed without building a memory intensive
object model or result set. XSL was supposedly designed to allow
efficient processing, for instance, by being side effect free.

Consider the following XML input

<foo>
<bar>quote of the day</bar>
<body> some useful content </body>
</foo>

and the following templates

<xsl:template match="foo">
  <HEADER> <xsl:apply-templates select="bar"/> </HEADER>

  <xsl:apply-templates select="body"/>

  </FOOTER> <xsl:apply-templates select="bar"/> </FOOTER>
</xsl:template>

According to the XSL design, I should only have
to apply the template to "bar" once, because the
side-effect-free-ness guarantees that the second
application will result in an identical result
fragment.


Now consider an XML input like this

<resultset>
<row>
   <col>Apple</col>
   <col>$1.25</col>
</row>

<row>
   <col>Orange</col>
   <col>$3.25</col>
</row>

<row>
   <col>Frape</col>
   <col>$0.35</col>
</row>
</resultset>

And the following stylesheet


<xsl:template match="resultset">

<TABLE>
  <xsl:apply-templates select="row"/>
</TABLE>

</xsl:template>


<xsl:template match="row">
<TR>   <xsl:apply-templates select="col"/> </TR>
</xsl:template>



<xsl:template match="col">
<TD> <xsl:apply-templates/> </TD>
</xsl:template>


Whether or not you consider this an interesting XSLT stylesheet,
I can assure you, there are many cases where XSLT stylesheets 
will be "simple" and won't have XPath's grabbing data from random
spots all over the XML document.

All I'm suggesting is, that perhaps an XSLT processor can "optimize" 
the stylesheet after it is loaded and detect how much state has
to be preserved for processing. It can always fall back on
a slower processing model, but if it could detect when a 
stylesheet could be "optimized" and give warning about what
constructs are likely to be slow, wouldn't that be great for
development in the same way that breakpoints and tracing are?


-Ray










 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread