I'm a bit confused by this code. $data is a set of elements having @x and @y elements. When you do

 for $d in $data return ($this.value + $d)

you're atomizing this element, which gives a zero-length string, and converting this to a number, which gives NaN.

Did you change the example for the sake of posting perhaps? If so, I think we need to see the real code, or at any rate, code which exhibits the problem. The optimizations Saxon does can be quite sensitive to small variations in the query.

You could certainly get some efficiency improvements by passing a sequence of numbers as the parameter value rather than a sequence of nodes from which numeric values need to be extracted. If you must use nodes, then using elements that are validated as numbers (by virtue of a schema) would help, because the conversion from string to number would only be done once for each node.

Michael Kay

On 02/02/2013 16:58, David Rudel wrote:
Hi all,

I know that using keys can often massively improve the speed of stylesheets that require repeated querying of some XML document. I was wondering if there are any ways to speed up a stylesheet that repeatedly makes use of all the nodes of a (temporary) document or sequence without any querying or even interest in the order those nodes are processed.

I've provided a toy example below. The elements in the sequence $data are used over and over again to calculate new values using a (made-up) formula until those values converge.

Is there any way to speed up this process with the fore-knowledge that these nodes are going to be used over and over again, perhaps over 1000 times as the template calls itself?

Would use of a tunnel parameter make sense to alert the compiler that the same value for "$data" is going to be used in each recursive call as the template calls itself? I didn't use tunnel parameters because there are no middle-templates to tunnel through, so didn't think it matched the expected use case, but perhaps it would prevent the compiler from making 1000 copies of the same variable.

Also, (likely less important) is there any real performance difference between using the expression "sum(for $d in $data return .....) versus the expression sum($data/(......))?


<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    exclude-result-prefixes="xs xdt udf saxon math fn err exsl date">

    <xsl:template match="/">
        <xsl:variable name="data" as="node()*">
            <point x="2" y="3"/>
            <point x="5" y="3"/>
            <point x="6" y="7"/>
            <point x="-3" y="8"/>
            <point x="6" y="-1"/>
            <point x="9" y="3"/>
            <point x="3" y="9"/>
            <point x="6" y="2"/>
        <xsl:for-each select="1 to 100">
            Starting Value=<xsl:value-of select="current()"/>
            <xsl:call-template name="process-step">
                <xsl:with-param name="last.value" select="0"/>
                <xsl:with-param name="this.value" select="current()"/>
                <xsl:with-param name="data" select="$data"/>

    <xsl:template name="process-step">
        <xsl:param name="last.value"/>
        <xsl:param name="this.value"/>
        <xsl:param name="data"/>
            <xsl:when test="abs($this.value - $last.value) lt 0.01">
                Final Value:<xsl:value-of select="$this.value"/>
                <xsl:variable name="next.value" select="sum(for $d in $data return ($this.value + $d) div (abs($this.value * $d) + 1))"/>
                <xsl:call-template name="process-step">
                    <xsl:with-param name="last.value" select="$this.value"/>
                    <xsl:with-param name="this.value" select="$next.value"/>
                    <xsl:with-param name="data" select="$data"/>



"A false conclusion, once arrived at and widely accepted is not dislodged easily, and the less it is understood, the more tenaciously it is held." - Cantor's Law of Preservation of Ignorance.

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:

saxon-help mailing list archived at http://saxon.markmail.org/