Bug #4916
closed
Range expression optimization not working
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
Description
Test case op:to RangeExpr-409d is running very slow. It appears not to be optimising the minimax test properly.
- Subject changed from Range expression optimization working to Range expression optimization not working
I suspect the optimisation can be simplified anyway. I think (A < N to M)
can be simplified to A < M
.
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.
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
.
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.
- Status changed from New to Resolved
- Applies to branch 10, trunk added
- Fix Committed on Branch 10, trunk added
- 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