About Arbortext Styler > Debugging Stylesheets > XPath Performance
  
XPath Performance
Although the use of XPath expressions in Arbortext Styler provides almost unlimited flexibility in terms of processing options, a stylesheet writer must take care when including them in order to avoid potential performance problems. Generally, if the use of XPath causes problems, it’s because it is easy to write expressions that require a lot of processing and matching work before they are resolved, or because the XPath engine is somewhat slower to process elements than, for example, the Arbortext Command Language (ACL). In particular, though, XPath expressions of the following types cause the most anomalies in terms of performance:
preceding:: or following:: expressions
This can mean that large parts of the document must be traversed for matching. If in turn the document is large this will require even more processing time. Avoid expressions of this
If you are working with the PTC ALD engine, using a predicate in the expression will limit the need to traverse the whole document. For example, count(preceding::para) will be slow, but preceding::para[1] will not.
All uses of preceding:: and following:: are slow when working with the FOSI engine.
Alternative methods of arriving at the same effect should also be explored, for example using the Insert > Element Content menu item in the Generated Text Editor. Quite often, the use of edited source also promotes efficiency of processing.
Expressions or sub-expressions that start with //
Using expressions of this type means that the whole document must be traversed for matching. If the document is large this will require substantial processing time.
If at all possible, change such expressions to use only single slashes. For example, the expression /*/abc will be considerably more efficient than //abc, especially when it is effected in sizeable documents. Note, however, that while this expression is more effective during processing, it requires more knowledge when developing the stylesheet since the developer must know the level at which the abc occurs in order to place the expression accordingly. Again, as an alternative, using the gentext menu options Insert > Element Content or Insert > Attribute Content instead of an XPath expression based on the // function will usually improve processing time.
position() or last() expressions that test position
Expressions of this nature cause processing issues when used in XPath tests for conditions, or in generated text.
Some alternatives methods of testing position via XPath in these situations are listed below:
Instead of position(), use count(preceding-sibling::*)+1
To test whether an element is the last child of its parent, i.e. to test position()=last(), use count(following-sibling::*)=0
To test whether an element is the first child of its parent use count(preceding-sibling::*)=0