[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] XPath "//", speed, and Saxon


Subject: RE: [xsl] XPath "//", speed, and Saxon
From: Lars Huttar <huttarl@xxxxxxxxx>
Date: Wed, 05 Nov 2008 10:19:55 -0600

Michael Kay (mi...@xxxxxxxxxxxx) wrote:
> Date:	10/31/2008 09:44:46 AM
> 
> Unfortunately it's very difficult to give good performance advice that applies across all processors.
> 
> There are several things Saxon does with leading // that are relevant.
> 
...

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


Thanks for the helpful explanations!

We are not running with schema-aware features at this point, but it's
interesting to know about the optimizations based on knowing the
possible input document structure, as well as the others.

Tony Graham wrote:
> On Mon, Nov 03 2008 12:51:58 +0000, mike@xxxxxxxxxxxx wrote:
> 
>> > 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.
> 
> To paraphrase Knuth (another giant who must surely have sore shoulders
> by now): premature optimisation is the root of all evil.

"Premature optimization" certainly applies to the problem I was dealing
with above... I assumed the performance problem was in the XSLT code,
and thought I was accomplishing something by optimizing those "//"
XPaths. But it turned out that the XSLT transformations (and everything
preceding them in the pipeline) ran in 90 seconds, whereas the whole
operation didn't finish in over 12 hours! The culprit was the final
serialization step... apparently something is wrong with the component
that writes the result to a file, such that it hangs if the input is too
large. That's my guess at this point anyway.

Lars


Current Thread
Keywords