[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XPath "//", speed, and Saxon
> 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/
|
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
|