Bug #1740

Performance regression for $x[$i]

Added by Michael Kay about 5 years ago. Updated about 5 years ago.

Start date:
Due date:
% Done:


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


Saxon 9.5 shows a performance regression when evaluating an expression such as

for $i in 1 to $n return $x[$i]

The cause is that the subscript expression is evaluated using a TailIterator, whose strategy depends on whether the iterator for $x is "grounded" or not. In this case the iterator is a ProgressiveIterator, which 9.4 decides is grounded, and 9.5 decides is not. In this instance the 9.4 strategy works better, despite forcing $x to be eagerly evaluated.

Reported by Gunther Rademacher on saxon-help list. See also MHK response on list.

test.xq (1.05 KB) Test query and measurements Michael Kay, 2013-04-24 12:14 test.xq


#1 Updated by Michael Kay about 5 years ago

  • Status changed from In Progress to Resolved

I've made a number of changes.

First, the MemoClosure ProgressiveIterator now reports itself as GROUNDED, which means that when subscripting access is made, the MemoClosure will be materialized in memory. This gets us back to the 9.4 measurements.

Second, to avoid eager evaluation of the MemoClosure, the subscript expression now checks whether the iterator is a ProgressiveIterator, and if it is, calls its itemAt() method which causes it to be evaluated as far as the requested item and no further.

Third, this logic is now replicated in the bytecode, which was previously not testing run-time conditions as carefully as the interpreted code was.

Finally, the bytecode is now improved in the case where it is statically known that the subscript is an integer; it avoids boxing the value and avoids the runtime isWholeNumber check, as well as the check against Integer.MAX_VALUE if the bounds are known statically.

The attached document contains the query and some measurements for different values of n.

#2 Updated by Michael Kay about 5 years ago

#3 Updated by O'Neil Delpratt about 5 years ago

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

Please register to edit this issue

Also available in: Atom PDF