Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Stylesheet optimisation
 > > > 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
