Project

Profile

Help

Bug #4916

closed

Range expression optimization not working

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

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2021-02-23
Due date:
% Done:

100%

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

Description

Test case op:to RangeExpr-409d is running very slow. It appears not to be optimising the minimax test properly.

Actions #1

Updated by Michael Kay about 3 years ago

  • Subject changed from Range expression optimization working to Range expression optimization not working
Actions #2

Updated by Michael Kay about 3 years ago

I suspect the optimisation can be simplified anyway. I think (A < N to M) can be simplified to A < M.

Actions #3

Updated by Michael Kay about 3 years ago

The optimisation is not kicking in because the precondition manyOperandIsLiftable() returns false.

This function only returns true if the parent expression is a context switching expression, which seems to make no sense.

Note: in 9.9 if the arguments are constant, we don't even get as far as considering optimisation, the expression is evaluated (slowly) during the type-checking phase. Also noted that the type checking of a the expression 1 to 10000000 in 9.9 is very slow: it appears to check that each item in the sequence is an integer!

The thinking behind the manyOperandIsLiftable test seems to be that scanning the numeric sequence to find the min and max may take longer than scanning it to find an item that is lt or gt the required value, because a min/max computation will never do an early exit. So it's justified only if the test is in a loop where the min/max computation can be reused by lifting it outside the loop. But with a range expression, the min/max computation is cheap, so this argument doesn't apply.

Actions #4

Updated by Michael Kay about 3 years ago

The problem with simplifying (A < N to M) to A < M is that it gives the wrong answer in the edge case when N > M.

Actions #5

Updated by Michael Kay about 3 years ago

I've got this working for "normal size" integer ranges, and for some constant "BigInteger" ranges. But the test case in RangeExpr-409d really isn't worth losing much sleep over: since the maximum length of a sequence is 2^31, ranges of the form M to N where M and N are both greater than 2^63 aren't going to arise very often in practice.

Actions #6

Updated by Michael Kay about 3 years ago

  • Status changed from New to Resolved
  • Applies to branch 10, trunk added
  • Fix Committed on Branch 10, trunk added
Actions #7

Updated by O'Neil Delpratt about 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.5 added

Bug fix applied to Saxon 10.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF