> This example from my tutorial about testing XSLT [1] shows 
> the result of profiling the same stylesheet and data in both 
> xsltproc and Saxon: the two XSLT processors agreed on which 
> were the two most time-intensive templates, but after that, 
> their results differed.

Profiling is useful, but it also has considerable limitations. The more
powerful the optimizer, the harder it is to relate what happens at run-time
to your original source code.

Hence the rhetorical question in the paper: "...but why is a simple <hr/> a
hotspot?" (Answer could be, for example, because it often fills a buffer in
the serializer causing the serializer to process the buffer contents)

Incidentally, one minor comment

>Only xsltproc provides a command-line switch for running the transformation
time multiple times 

Saxon has had such a switch for some time, though only recent releases have
documented it (-repeat:99).

I think there's another important (if obvious) point that's not made in the
paper: don't assume that your performance problem is in the XSLT code until
you've drilled down to that level. I did a bit of tuning for a client
recently where it turned out 80% of the cost was spent in some simple
user-written code to generate the XML input for the transformation.

Michael Kay
http://www.saxonica.com/