Re: Practical Suggestion for XSLT Performance Improvement

["Clark C. Evans" <clark.evans@xxxxxxxxxxxxxxxxxxxx>]

On Sun, 10 Oct 1999, Oren Ben-Kiki wrote:
> Actually, it is worse then that. The war is lost if you use
> select="$complicated-path" _anywhere at all_, even in the humblest
> <xsl:value-of>. You also get in trouble by using multiple
> <xsl:apply-templates> on the same input tree fragment

Oren, thanks for responding!  To have one-pass stream 
processing (XSLTS), extreme (but not unreasonable) limits 
must be placed on the stylesheet:

A. Any directives corresponding to a re-ordering of
   events (forcing multi-pass situation):

   1.  <xsl:apply-templates/> may not contain a
       match clause
   
   2.  <xsl:for-each/> may not be used with any xpath
       expression; directly or indirectly through the
       use of a variable.  <xsl:for-each/> may be used
       on a document fragment returned in named pipe stream.

B. <xsl:value-of/> may only be used with a constant and/or 
   limited proximity xpath expressions,  allowing:

   1. The current element's name and attributes.  
      
      In this case, blocking for attributes is resonable.

   2. Ancestor elements including their name and 
      attributes, but not content or other children.
      
      An ancestor element stack will provide this
      functionality with little overhead.

   3. References to prior elements' name, attributes,
      and text content, provided that the xpath 
      reference is a constant involving only parameters 
      set globally before processing commenses.
      
      The stylesheet can be pre-processed to generate
      a list of tags to be stored.  Then, the values
      of such tags can be filled in as the stream runs
      across those values.  A simple hashtable will
      provide this functionality with little overhead.

   4. The name, attributes, and content of immediate
      childless children occuring before any child
      with children.

      In this case, blocking for "tiny" child elements
      which are being used like attributes before 
      proceeding is resonable.  However, this look-ahead
      should stop with the first element that has 
      children.  Since a DTD can specify the ordering
      of children this is very resonable.
       
      Note that text nodes following a child with
      children is only accessable after the call
      to <xsl:apply-templates/>

I'm sure I've missed a few, but something like this
is what I had in mind.    Then, the named-pipe mechanism
can be used for passing child/grandchild information
back up to parents.

> and passing data
> computed in one invocation to another.

You can't do this anyway can you?  I know you
can call-template and pass parameters, but I 
don't see this as a problem.
  
> In short, the war is probably lost anyway. I note that the proposed
> recommendation still restricts the use of result tree fragments, as if
> there's still a chance of winning it.

You don't think that there is a chance?  Also, I see two concerns:

1. Efficienty (not storing too much)
2. Modularity (having re-usable #includes )

The modularity also comes with the "restrictions"

> Well, it is listed in the considered
> future features list, so not all hope is lost...

I've beenthinking that the "return pipe" idea
is just a way to allow XSL sthylesheets to be
modular, i.e., applying XSL rescursively using
an XML DTD as an interface.

Perhaps there are two ideas here, the first one
describing a limited subset of XSL for stream 
procesors; and the second one is more of a
"network of stream processors" working togehter
in a generative manner.   So, mabye it is not
at all appropriate to build in a "return-pipe"
mechanism, but it may be more appropriate to 
describe a "reaction document" (to use Stefano's
idea in the Coccon project), which documents a 
collaboration of stream processors working together 
in a recursive manner.  Then, some framework would
have to be built which animates this larger structure.

Does this make sense?

Clark



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