Short circuit evaluation
kwboone opened this issue · comments
Shouldn't cql_engine/cql-engine/src/main/java/org/opencds/cqf/cql/elm/execution/AndEvaluator.java and OrEvaluator do short circuit evalutation? I tried to protect some code against null proliferation only to find out that short circuiting isn't present. That was a surprise.
Of the left operand is false, the right operand need not be evaluated in an AND expression.
If the right operand is true, the left operand need not be evaluated in an OR expression.
Does CQL have a different expectation. I certainly didn't.
Like SQL, CQL does not use short-circuit evaluation to ensure that logic can be reorganized by an optimizer. There are other ways to prevent null propagation though, specifically the conditional operator (if..then..else) and the Coalesce() operator.
Looking through the spec though, I was sure I had included that, but I can't find it anywhere, so I'm logging an STU comment to clarify that behavior.
Looking further, it is in the FHIRPath spec, section 6.5., Boolean Logic. I'll use the same language for the STU comment.
OK, so I get it, and it's an implementation dependency that CAN be implemented, but need not. So for the expression compiler, you keep both. But for the evaluator, it would be good TO implement short circuiting and I'll explain why:
-
The code is still a little bit rough in places, the reason I was trying to avoid a test using short circuit evaluation was because it was throwing an exception instead of properly dealing with null values. I've actually managed to fix my null problem another way, but it will improve the interpreted execution.
-
Performance can be impacted through careful use of short circuit evaluation. If an expression doesn't need to be evaluated, then that's extra stuff that doesn't need to be looked at. In at least one case I know I can do A if either B or C is true, and B is cheaper to check than C. So I (and many other engineers I know) have already been trained to write my code in a certain way so that I do the cheap stuff first in my boolean expressions. So the execution path in the Interpreter should probably take advantage of this opportunity to speed up processing for the end user. A lot of engineers have been trained that way, take advantage of it ;-)