> 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format