Bug #2307

Optimization disabled in 1.0 compatibility mode

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

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


Saxon-EE attempts to optimize expressions such as //*[@name=$xyz] to use a document-level index (in effect, a system-generated xsl:key definition).

In 9.6, this optimization is disabled if the expression is in 1.0 compatibility mode. In 9.5, this was not the case, creating a performance regression for affected stylesheets.

There are some cases where disabling the optimization is legitimate, and it was almost certainly done to eliminate bugs. However, doing this for all expressions in 1.0 mode is overkill.

Cases where the optimization does not work include all cases where the fixed comparand ($xyz in the above example) might turn out to be boolean or numeric, because the semantics of the "=" operator in 1.0 mode for such cases make indexing highly complex. (A more elaborate optimization would generate code that builds indexes selectively based on the run-time type of the expression). But Saxon already works out cases where there is enough type information to know that the 2.0 comparison semantics can be used, and in such cases suppressing the optimisation is unnecessary.

The same applies to variable-level indexes used for expressions such as @$x[@name=$abc]@.


#1 Updated by Michael Kay almost 7 years ago

  • Priority changed from Low to Normal

I am committing a patch (for 9.6 and 9.7) whose effect is:

(a) the test which prevents filter expressions being turned into calls on key() when in 1.0 mode is removed.

(b) a test is added to the isIndexableComparison() method which deems a GeneralComparison10 to be non-indexable. The expression class GeneralComparison10 is used for an "=" comparison in 1.0 mode if there is any possibility that either operand might be a boolean or a number. (This will include, for example, all cases where an operand is a reference to a template or a function parameter with no "as" clause).

The effect is that predicates such as //x[@a=$V] become indexable (in 1.0 mode) provided that the expression $V is known to yield a string or a node-set.

Note: in 2.0 mode, Saxon allows indexing where the value is numeric, even though the semantics of "=" in this case are still rather complex. It would be possible to do better in the 1.0 case. But is it worth the effort?

#2 Updated by Michael Kay almost 7 years ago

  • Status changed from In Progress to Resolved

#3 Updated by O'Neil Delpratt almost 7 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to

Bug fix applied in the Saxon maintenance release.

#4 Updated by O'Neil Delpratt about 6 years ago

  • Sprint/Milestone set to
  • Applies to branch 9.6 added
  • Fix Committed on Branch 9.6 added
  • Fixed in Maintenance Release added

Please register to edit this issue

Also available in: Atom PDF