-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rule scoping tweaks #1714
rule scoping tweaks #1714
Conversation
since the primary operation is `contain()`, set is more appropriate than tuple.
make a local copy of the scopes dict
im worried this will interact poorly with our rule cache, unless we add more handling there, which needs more testing. so, since the filtering likely has only a small impact on performance, revert the rule filtering changes for simplicity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Thanks @williballenthin !
@@ -1280,11 +1280,6 @@ def __init__( | |||
|
|||
ensure_rule_dependencies_are_met(rules) | |||
|
|||
if rules_filter_func: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The addition of ruleset filtering might be premature optimization in the mean time anyways. So I suggest we think about measuring the performance difference first before prioritizing updating the cache and adding this back in.
…into fix/issue-1697-1
c001c88
into
dynamic-feature-extraction
please review and merge #1713 first
This PR makes some minor tweaks to how the
Scopes
object is parsed, nothing notable, except maybe using a set instead of tuple, and avoiding modifying passed-in arguments.This PR also reverts the filtering of rules by the current analysis flavor. As I studied #1697, I noticed that this may influence the rule cache (which is already slightly brittle) which I think we should try to avoid. Rather than spend more time on understanding the interplay, I'd propose simplifying the code by reverting to the old rule set construction. This might have a small performance overhead, since we keep around rules that are not relevant to the current flavor, but its simple and obvious.
Checklist