Re: Practical Suggestion for XSLT Performance Improvement

Subject: Re: Practical Suggestion for XSLT Performance Improvement
From: "Clark C. Evans" <clark.evans@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 7 Oct 1999 09:12:00 -0400 (EDT)
On Thu, 7 Oct 1999, Christopher R. Maden wrote:
> Child-to-parent communication would certainly improve performance 
> for the task you describe, but it would blow incremental rendering 
> in browsers and editors all to hell.

Chris, 

I don't see how what I was suggesting would at all hurt 
incremental rendering.  If anything it would improve the
situation beacuse the input stream would be discarded
"by default" unless the stylesheet author "marked" the
information as something which is needed later.  I was
also proposing an aggregate storage mechanism since the 
requirement to generate a tagged sum seems common;
and it would be a pity to allocate memory to store
several hundred nodes only to add them later and then
de-allocate the memory.  In this way, a majority of 
the document need not be stored in the browser's 
memory -- giving more CPU and memory to code which does 
the actual rendering.

For example, as orders came in, they could be
rendered almost immediately as a sequential list 
of blocks.  As each child template which matches
an order element, it would send its total to the
parent template (hopefully with the XSL engine
only storing the cummulative value).  So that when
all child orders are processed, the template which
matched the day tag could extract the total value
and write this out to the user.  Then, perhaps this
template could  put its total on the stack so that
a template matching the week tag would have the weeks
numbers at its fingertips, etc.

  If anything, this recursive model, leveraging not
  only the begin tag for an element, but also the
  end tag, would support incremental rendering far 
  more efficiently than the iterative 
  for-each/xpath/dom approach.

Now, the downside is apparent:  the stylesheet
author would have to specify what information
must be saved... since otherwise it is discarded
to the bit bucket (after, ofcourse, the corresponding
incremental output stream had been generated).

If you wanted to get "really" detailed, you can think
of this method as an underlying "assembler" language
produced by an XSL compiler; where the child/parent
communication is really just a description of stack
usage.  I'm asking is to allow the stylesheet author 
access to this "lower-level" description, much like 
you can put assembler instructions in C; only I'd 
like to see one version of assembler.

> That doesn't mean I'm unsympathetic, and I think 
> there's certainly room for something like what you 
> describe.  Perhaps XQL will be that something; perhaps 
> a set of XSLT extensions for large dataset processing
> will emerge.  But don't try to sharpen my hammer because 
> you want to drill holes with it.

I hope this is a better explanation of what I am thinking.
Perhaps you are right... and it is more like a "query-plan"
generated from an SQL query.  A lower-level, simpler, but
more tedious description of the process ;)

Best wishes,

Clark


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


Current Thread