Re: Practical Suggestion for XSLT Performance Improvement

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