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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Practical Suggestion for XSLT P, Christopher R. Maden | Thread | RE: Practical Suggestion for XSLT P, Kay Michael |
Re: Schema definition, Eric van der Vlist | Date | RE: Iterative XML Handling, Anthony . Behan |
Month |