[
Lists Home |
Date Index |
Thread Index
]
Hi Mike,
> Either would do. The above are the only template rules in the
> stylesheet. The first template rule is the only thing in the
> stylesheet that can produce any output. Therefore you know that if
> you are processing a node that cannot have row[id='0432'] as a
> descendant, you can skip it and its entire subtree.
>
> As I say, this is an example where schema knowledge could help
> greatly. The rule would be "if none of the descendants of this node
> can match a template rule that produces output, then don't process
> this subtree." The question is, would this rule be triggered
> sufficiently often to justify including it in the optimizer?
As with most of these optimisations, an alternative would be to
perform a kind of linting service for the XSLT authors and point out
that they would get much better performance if they rewrote their
stylesheet. Doing:
<xsl:apply-templates select="/table/row[id='0432'][1]" />
for example, would speed things up no end.
But looking at it another way -- say that you've looked at the
stylesheet and you've noticed that you only need to process elements
that contain an element that matches row[id='0432']. Then there are
two ways you can use that information:
- you can look in the schema or DTD to find out what kinds of
elements can contain a row element with an id child with the value
'0432' and all their ancestors, and then, while parsing the
document, flag those elements that are of any of those types
- while parsing, you can locate the row element with an id with the
value '0432' and place a flag on it and all its ancestors
Isn't the latter easier to do and more flexible?
> (Alternatively, I might include it anyway because I'm only really
> interested in optimizing the cases that occur in benchmarks).
Quite. I think it's unlikely that this kind of arrangement would occur
in real life. In real life, the '0432' would be a parameter passed
into the stylesheet, and as you know, you can't use parameters in
template matches, so there'd either be the pull approach as above, or
a push approach that looked like:
<xsl:template match="row">
<xsl:if test="id = $id">
...
</xsl:if>
</xsl:template>
Although I guess since that restriction is lifted in XSLT 2.0, it
could happen.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
