RE: Performance

Subject: RE: Performance
From: Kay Michael <Michael.Kay@xxxxxxx>
Date: Fri, 10 Mar 2000 17:33:38 -0000
> 1)  Is the above sentence an issue - are there actually noticable
> performance hits for doing certain XSL actions.  I have heard 
> using "//" to access descendants can be a penalty but are there other 
> obvious "things one should avoid".  If there are, is there a list of these
or 
> documentation that describes them anywhere.

Yes, there are things you should avoid. Many of the details will be
product-dependant but there are probably some things that will be slow on
any processor. No, there is no decent performance guidance that I'm aware of
(I certainly haven't published any for Saxon and would have trouble doing
so). Best advice is to try several approaches and measure them.

If you think about how many nodes in the tree a naive processor would need
to visit to evaluate the expression, you're probably not too far off the
mark. For example, a naive processor needs to visit every node in the
document to evaluate //x. Actually because //x means
/descendant-or-self::*/child::x, it needs to visit every node, and then
visit all that node's children. Some processors might find a better way
(e.g. they might maintain an index of elements by name) but as your first
guess, assume not.
> 
> 
> Is it better for performance reasons to embed a complete list of 24
> <timeitem> elements inside of each <time> element 

I think it's very unlikely that replicating data in the source XML document
is ever a good idea, unless the access path ot get to it is really
contorted. Getting the parent node should be very fast, probably faster than
getting an attribute.

>         <xsl:when test="../time/@selected=value">

Do you really want to mark the value as selected if there is ANY time
element matching this selection? If not, passing the value of @selected as a
parameter to this template might be worthwhile (one of the few uses I have
seen for parameters on apply-templates).

> 
> If sharing the <timeitem> elements is not a performance 
> issue, is there any way in XML to share all those items from one point of
access 
> as they are really only there for display.

If they are fixed, you could put them in your stylesheet rather than in the
source file. Might not give any performance benefits, but seems more logical
to me.

Mike Kay


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


Current Thread