Bug #6607
openType-checking of maps - performance issue
0%
Description
Shown by QT3 test case fn-parse-json-056
In order to test whether a map conforms to the required type map(*), the code in TypeChecker.staticTypeCheck()
is calling map.getItemType()
which is an expensive operation as it involves examining all the entries in the map.
Updated by Michael Kay 10 days ago
What's happening here is a call on map:keys(parse-json('....'))
where the call on parse-json()
is preevaluated to a Literal
map before the call on map:keys is type checked. The type checking code tries to determine the static type of the expression being passed as the first argument, and in this case the expression is a Literal
, so it ends up trying to determine the item type of the map.
Perhaps rather than calling the method Expression.getItemType()
there should be a method Expression.isItemTypeSubtypeOf(X)
.That's a rather substantial change but the new method could be given a default implementation that calls getItemType()
, and could have a custom implementation for literals.
Alternatively, and perhaps more simply, Literal
could return true for implementsStaticTypeCheck()
, in which case it would call Literal.staticTypeCheck()
, which achieves much the same thing. Current expressions that implement this method are things like Block and Choose, which go on to check not just that the expression as a whole delivers the right type, but that every operand does so.
Updated by Michael Kay 10 days ago
Added a fast path to TypeChecker.staticTypeCheck
:
if (supplied instanceof Literal && ((Literal)supplied).isInstance(req, th)) {
return supplied;
}
This is going to catch all cases where a function is called with a literal argument that matches the required type, so the benefit could be substantial.
Updated by Michael Kay 7 days ago
- Status changed from New to Resolved
- Applies to branch 12, trunk added
- Fix Committed on Branch 12, trunk added
- Platforms .NET, Java added
Updated by Michael Kay 3 days ago
- Status changed from Resolved to In Progress
This code causes a performance regression for type-checking of an expression such as 1 to 1000000, where Expression.getItemType() is fast, but checking the type of the instance is slow. That particular example is easily fixed in Literal.isInstance()
by special-casing, but there may be other cases where Expression.getItemType()
is more effective than Literal.isInstance()
.
Please register to edit this issue