-
Notifications
You must be signed in to change notification settings - Fork 43
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
Cache RuleTypeEngine instances in Executor #3741
Conversation
744d070
to
e1a9e0e
Compare
This simplifies an upcoming PR, and also addresses a comment in the code about avoiding continuously re-querying for rule types. This PR changes the executor to load all relevant rule types before evaluation and construct RuleTypeEngine instances for each. These are then stored in a cache and used during rule evaluation. Certain aspects of this change (specifically, the need to query for the rule type ID) are a bit clunky, but will be simplified in an upcoming PR.
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.
LGTM. Let's run some smoke tests before merging this. Wanna make sure we're in a good state before this.
@@ -131,7 +131,6 @@ type EvalStatusParams struct { | |||
Result *Result | |||
Profile *pb.Profile | |||
Rule *pb.Profile_Rule | |||
RuleTypeName string |
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.
Populating the eval params struct with the rule type name was awkward with in the new codepath for loading rule types, and it was only used in one place for evaluation telemetry. I decided instead to pass the rule type name via a different mechanism to the telemetry code.
This simplifies an upcoming PR, and also addresses a comment in the code about the need to cache rule type lookups. This PR changes the executor to load all relevant rule types before evaluation, and construct RuleTypeEngine instances for each. The RuleTypeEngine instances are stored in a cache and reused during rule evaluation, instead of the current approach which constructs a new RuleTypeEngine for each rule instance which is evaluated.
Certain aspects of this change (specifically, the need to query for the rule type ID) are a bit clunky, but will be simplified in an upcoming PR.
Summary
Provide a brief overview of the changes and the issue being addressed.
Explain the rationale and any background necessary for understanding the changes.
List dependencies required by this change, if any.
Fixes #(related issue)
Change Type
Mark the type of change your PR introduces:
Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist: