Re: [xsl] XPath perfomance in attributes or nodes?

[Trevor Nash <tcn@xxxxxxxxxxxxx>]

>When is the cost of building the index offset by the performance gain ?
That is highly dependent on the processor and the input document, but
you are right to be suspicious of the statement 'a key is *always*
faster'.  In my experience with Saxon and expressions of the form
//x[@y='z'] applied to a particular document, I found it was worth
using key() after just a few accesses.


>    <xsl:apply-templates select="/doc/elt[@att=$param]" />

Where you are doing *one* access only, this will usually be the faster
option.  Two reasons:
1. The one you have probably guessed already, you save on the index
building process (less time and less space)
2. To build the index, key() will examine *every* node in the
document.  This may be true even if you write match="/doc/elt" because
the processor is unlikely to have been optimised for this case.

But there is something else you should think about: your input
document is large and (perhaps?) fairly static.  So you don't want to
parse it for every transformation.  So, it should be cached in some
way.

Question: what if you could also cache the index that goes with it?
(recall that Mike mentioned that indexes are not global things for a
stylesheet, they exist in relation to a specific input document).
Then, you could use key() and get a large performance boost for all
but the first transform.

Of course, how you do this, and whether it is possible at all, depends
on your environment and what processor you are using.

And never forget that the biggest performance gains are to be had by
looking at the overall design, not the effect of individual
statements.

And the only definitive answer you will ever get is by doing the
experiment.

Regards,
Trevor Nash
--
Traditional training & distance learning,
Consultancy by email

Melvaig Software Engineering Limited
voice:     +44 (0) 1445 771 271 
email:     tcn@xxxxxxxxxxxxx

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