highlight on the caching issue

Hi,

>From my point of view, the most important issues for performance aren't
however about tools and platforms but the following ones:
1. Do you avoid re-parsing unchanged XML files?
2. Do you avoid re-processing for the same arguments?
3. Are the most common processings the fastest?
4. Do small variations in arguments or data imply heavy re-processings?
5. Are the complexities of the algorithms the lowest possible?

My answers to these three questions would be:
1. Yes, with a cache for DOM trees.
2. Yes, with a cache for final results (HTML) also.
3. Yes, with a cache allowing its most requested entries to remain the
longest.
4. No, with a cache handling dependencies (like the unix make command does),
i.e. knowing that a result entry depends on the input data and on the
stylesheet used: if one of them is invalidated, the result should also be
invalidated.
5. That's the BIG point!
    a. As a good relational model is essential to achieve scalability with a
RDBMS, a good DTD is of the most importance with XML.
    b. As in all programming languages but even more here as XSLT is
rule-based and often interpreted, the choice of the used algorithms should
be carefully made.

I'm quite puzzled by the lack of interest in the caching issue over the XSL
community. Very few processors integrates a cache out of the box, leading to
a bad reputation for XSLT in terms of performance. This feature is often
ignored in benchmarks: is a processor like MSXML said fast  just because it
integrates a cache?

Tangi Vass


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