Subject: Re: Practical Suggestion for XSLT Performance Improvement From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Thu, 7 Oct 1999 10:11:10 +0200 |
For good or bad, XSLT was designed as a "single pass on the output document" instead of "single pass on the input document". Using streams for achieving the first goal is an old technique; those interested should take a look as how the M4 macro processor handles the issue, for example (anyone has any idea when M4 was written?). XSLT's approach does potentially cause performance problems for large input documents. However, I'm not convinced that solving the current performance problem calls for the changes you propose. I suspect that simply removing the restrictions on matching on result tree fragments would solve most of the problem. This is much more in the XSLT spirit then using streams or mutable hash tables. It would be interesting to repeat the benchmarks on an XSLT processor which supports this extension and check the relative speed of this approach. Until the time that this restriction is lifted, it can be approximated by using string operations. Using a template which accepts the current totals as a string containing "<product>:<sum>:<product>:<sum>:..." and evaluates to an updated one, it is possible to do a single pass on the input collecting the sums. Then implement a single pass on the string generating the output. This is terribly inelegant, however. The real value of such hacks is in proving that the perceived advantages for restricting matching on result tree fragments are illusory:-) Have fun, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Practical Suggestion for XSLT Perfo, Clark C. Evans | Thread | Re: Practical Suggestion for XSLT P, James Clark |
Schema definition, Eric van der Vlist | Date | Re: Practical Suggestion for XSLT P, Christopher R. Maden |
Month |