Michael Kay (mi(_dot_)(_dot_)(_dot_)(_at_)saxonica(_dot_)com) 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(_at_)saxonica(_dot_)com 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
--~------------------------------------------------------------------
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>
--~--