XSLT Profilers

Posted on: Saturday, February 16th, 2008 at 6:47 pm

PHP recently announced PHP 5.3 which will include an XSLT profiler that can be invoked from within code. Current versions of PHP and the Microsoft one can invoke an XSLT profiler through the command line or against static XML/XSL files only, so being able to call it from within code is quite useful.

The run time invocation is really useful because if you are passing parameters into the XSLT or are generating the XML through DOM programmatically it is easier to profile. Otherwise, you need to capture the XML generated and save it, then invoke a profiler separately from the command line.

An example of calling it from within PHP is this (taken from a SitePoint article explaining the new features — see previous link):

$doc = new DOMDocument();
$xsl = new XSLTProcessor();

$doc->load('./lib/collection.xsl');
$xsl->importStyleSheet($doc);

$doc->load('./lib/collection.xml');
$xsl->setProfiling("/tmp/xslt-profiling.txt");
echo $xsl->transformToXML($doc);

echo '<h2>Profile report</h2>';
echo '<pre>' . file_get_contents( '/tmp/xslt-profiling.txt' ) . '</pre>';

The profilers in oXygen and XML Spy look quite useful too (not used them, though heard about them).

I have not used XSLT profilers extensively. Just once in a blue moon. Some of the XSLT performance tips I have written earlier seems to have served me well, thus far, but I think more regular use of these profilers will be important.

Have you used other profilers for XSLT? What are they like?

Have you used other profilers that you can invoke from your code, rather than from an IDE or command line?

Do you find that to be useful or in the end is it just as easy to capture the XML and run the profiler in the IDE (which usually has a more powerful GUI to splice and dice the profile data)?

What about XSLT code coverage?

Is anyone aware of any good XSLT code coverage tools?

The reason this is important is that as well as getting good performance, it is important to know if you are exercising all your XSLT code or not.

This would be particularly useful when integrated with unit-tested XSLTs (which I will be writing about shortly!).

Image credits

“Stopwatch” by jamieriddell from flickr. See the original image at http://www.flickr.com/photos/jamieriddell/2183060366/.

These icons link to social bookmarking sites where readers can share and discover new web pages.

About this post

This entry was posted on Saturday, February 16th, 2008 at 6:47 pm and is filed under XSLT. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “XSLT Profilers”

On February 17th, 2008 at 11:08 pm Miguel de Melo said :

My experience with profilers is restricted to IDE tools, oXygen and Stylus Studio, both provide a good graphical representation of code reusability and times used to process each section of the code, as well as good stack reports, and link backs to code.

To be fair I haven’t used them as often as I would like to, but I can remember at least one time where it became a life saver for hundreds of users of a large publishing system. There was nothing wrong with the code but the underlying system was supporting the dynamic access of hundreds of documents from the file system using XSL extensions, just to then only extract the title out of full article documents and build a URL to the page. The XSL profiler identified what part of the XSL framework was causing problems, and just by looking at the graphical report it became immediately apparent exactly what line of code was causing havoc.

We then just captured the title of articles in a database table and from then on instead of opening full XML documents, the XSL Extension returned a nodeset with the titles of articles and their respective URLs. We gained a 500% performance increase for that process.
On February 18th, 2008 at 10:20 am Anup Shah said :

@Miguel: that was a good performance boost! I can imagine when the XSLT is using Extension Objects to call through to the database etc, then the profilers are more useful.

I usually try to see if I can “prepare” the XML for the XSLT so the code that gets the XML may perhaps be able to get the data from the database and merge it somehow with the rest of the XML. (But you need to profile that anyway!)

But I like that use of XSLT.

As an aside, I am hoping to shortly post something about using XSLT in MVC, and although the XSLT itself could be a controller (more like MVTemplate!), I am going to talk about it being used in a view. [There will be a post before that to explain why!]

onenaught.com

Main Menu

XSLT Profilers