afs commented on issue #3323:
URL: https://github.com/apache/jena/issues/3323#issuecomment-3094485153
Great analysis!
However, I'm not so keen on `isLikelyToEvaluate` as an approach because it's
for all cases and all `Expr` - a wider contract.
Instead, change `E_Coalesce` to optimize a known case.
```java
@Override
public NodeValue evalSpecial(Binding binding, FunctionEnv env) {
for ( Expr expr : super.getArgs() ) {
if ( binding != null && expr.isVariable() ) {
// The case of an argument being a variable.
// Do directly - COALESCE(?X, ...) is a common usage
// pattern and this avoids relying on an exception.
if ( binding == null )
continue;
Var var = expr.getExprVar().asVar();
if ( ! binding.contains(var) )
continue;
return expr.eval(binding, env);
}
try {
NodeValue nv = expr.eval(binding, env);
return nv;
} catch (ExprEvalException ex) {}
}
throw new ExprEvalException("COALESCE: no value");
}
```
By the way - I'd like to understand the costs. `ExprEvalException` is
(should) already avoid creating the stacktrace for the exception. The actual
exception is `VariableNotBoundException`, a subclass of `ExprEvalException`.
Is it the `try{}` block itself, or the catching the exception that is the
cost point? and is using a subclass a factor?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
