Recently I had to revisit the coding I did on the XSLT reporting module, to solve a problem with speed and file sizes when the client was run on a lot of data (when I say a lot of data, I mean a full system-wide report). It wasn’t unreasonable that the output was very large, as this is just how the report will end up no matter what we do, besides shaving the odd unnecessary tag off here and there, but taking 20minutes to produce a report, using 1.5GB of virtual memory, is the main problem.

Since time is always of the essence I had to attempt to fix whatever I could, and I came up with a few pointers which successfully decreased the transformation processing time. Take this slightly modified example XML file:

<Bookstore>
<genre name="Business">
<book ISBN="BU1032" Title="The Busy Executive's Database Guide" Price="19.99">
<chapter num="1" name="Introduction">
Abstract...
</chapter>
<chapter num="2" name="Body">
Abstract...
</chapter>
</book>
<book ISBN="BU2075" Title="You Can Combat Computer Stress!" Price="2.99">
<chapter num="1" name="Introduction">
Abstract...
</chapter>
<chapter num="2" name="Body">
Abstract...
</chapter>
<chapter num="3" name="Conclusion">
Abstract...
</chapter>
</book>
<book ISBN="BU7832" Title="Straight Talk About Computers" Price="19.99">
<chapter num="1" name="Introduction">
Abstract...
</chapter>
<chapter num="2" name="Body">
Abstract...
</chapter>
</book>
</genre>
</Bookstore>

If we want to get a list of all books with at least 3 chapters, no matter which genre it is, we may use XQuery in the form of //chapter[@num='3']/../@Title which should return the book “You Can Combat Computer Stress!”, and indeed it does:

A: Title = You Can Combat Computer Stress!

Looking at this code we can see that it begins with the global search specifier // without a specified parent, which will enumerate every node in the document in order to find a chapter node.

To optimise this, there is a simple change we can make to the XQuery that will simply change the global search to a fully qualified path name. Change the // to /Bookstore/genre/book/ which will now be:

/Bookstore/genre/book/chapter[@num='3']/../@Title

This returns:

A: Title = You Can Combat Computer Stress!

The result is the same, but the XSLT processor no longer has to look around for the node we want to select.

In this particular scenario, there would be virtually no benefit in optimising this, but optimising this XQuery to be run on a very large XML database where it may be run many times over would reduce the total processing time by quite an amount.

NOTE: this will only work in XQuery code that doesn't look for nodes that are defined in more than one place. If the element you are searching for will always be in a fixed hierarchy, this method should work and help your transformations.