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/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--