Guards: Cache nullGuard predicate. #20237
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A recent QA run highlighted a performance regression on a single repo: total analysis time went from 3mins to 41mins. I tracked down the cause to a poor join-order in a non-recursive instance of the
forex
in thewrapperGuard
predicate. The predicate is actually recursive, but was being recomputed in a non-recursive setting since its recursion goes through cached dependencies but was (transitively) used in the non-cachednullGuard
predicate, which is publicly exposed.This PR fixes the problem by including the
nullGuard
predicate in the set of cached predicates in the Guards library.I could reproduce the performance problem locally and verified that this PR fixed the issue.
Ignore white-space when reviewing to minimize the diff.