Daniel Veillard wrote:
the problem is that those bottlenecks are likely to be implementation
dependant,
That's OK; I need to optimize them in general, but also for the specific
XSLT processor I use. I don't distribute these XSLTs for use with all
processors; instead I simple run them with one processor, here (two
versions of Saxon actually).
so generic profiling is unlikely to give good results (well
unless getting a model of the processor and running some serious
computations).
Any improvement is better than none. And I suspect that in fact there
are many types of bottlenecks which slow down all processors, such as
match="//foo", or stuff like
<t:param name="bar" select="document(doc.xml)/bar"/>
<t:param name="baz" select="document(doc.xml)/bar/baz"/>
instead of
<t:param name="doc" select="document(doc.xml)"/>
<t:param name="bar" select="$doc/bar"/>
<t:param name="baz" select="$bar/baz"/>
I'd like to be told stuff like
"Saxon spent 70% of his time in line 5 columns 7-20 of foo.xslt."
xsltproc has a --profile [*] option where it dumps statistics about time
spent.
Sounds great!
Now I just have to wait until xsltproc supports XSLT2 ;)
The granularity is the template, not line blocks though.
I think I'd need more details than that.
[*] --norman is an alias for this option, guess why :-)
Norman Walsh coded or designed it?
Tobi
--
http://www.pinkjuice.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list