[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: speed optimization
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." 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|