Bug #3465: Loop-lifting optimization can make code non-streamable - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3465

closed

Loop-lifting optimization can make code non-streamable

Added by Michael Kay almost 7 years ago. Updated almost 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Streaming

Sprint/Milestone:

Start date:

2017-10-03

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.8, trunk

Fix Committed on Branch:

9.8, trunk

Fixed in Maintenance Release:

9.8.0.5

Platforms:

Description

Martin Honnen on the help forum has provided a test case where loop lifting makes streamable code non-streamable. Specifically, in the streamable template

   <xsl:template match="itemA">
        <xsl:value-of select="for $col in $columns return @*[name() eq $col] || ''" separator=","/>
    </xsl:template>

the expression @* is lifted out of the for-expression. This means it gets bound to a local variable, and binding of streamed nodes to a variable is not allowed.

Actions

Copy link

Updated by Michael Kay almost 7 years ago

We do all optimization including loop-lifting before we do any streamability analysis, although we do know during optimization (and take into account) that the code is intended to be streamable. Possible solutions are:

Don't do any loop-lifting if the code is intended to be streamable. Seems a bit draconian.
Don't loop-lift any expressions that return nodes if the code is intended to be streamable. This is sufficient to prevent this particular problem, of binding streamed nodes to an injected variable. But it could also stop useful optimizations in streaming code, such as

<xsl:for-each select="//streamed-node[@x = $lookup-doc/x/y/z/@id]">...

(Though in this example, we would loop-lift the expression data($lookup-doc/x/y/z/@id), which doesn't return nodes and is therefore OK.)

As (2) above, but with exceptions: for example, allow loop-lifting of an expression if it has no dependency on the focus, or on the first argument of a streamable stylesheet function, or on current() or current-group(). Seems plenty of potential here for getting the rules wrong...
Introduce a new "special property" for expressions: @RETURNS_STREAMED_NODES@. This would in effect bring forward a small part of the streamability analysis. I don't see this as being especially difficult to compute, but it's perhaps a bit ambitious to do in a maintenance patch.

Actions

Copy link