-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Performance impact switching to some .. in
iteration syntax
#6740
Comments
Good find! Looking at the output from the compiler (using opa-explorer), the nested iteration is left intact, while the all_operations contains operation if {
allowed_operation := role_allowed_operations[_]
operation := allowed_operation[_]
} Which seems to have the same negative impact compared to nesting the loop. I'd guess it's got something to do with all the intermediate values having to be realized on the "Rego side", but someone else (@johanfylling?) likely knows better :) If that is the case, it would be nice if the compiler could identify sequences of (btw, I think "more performant" should be "less performant" in the description 🙂) |
I can confirm that evaluation of the "short-form" enumeration |
Short description
There appears to be situations where
some .. in
iteration syntax is less performant than the legacy bracket syntax.Examples:
I ran some benchmarks (see rego files attached for full policy), and i'm seeing a noticeable changes in eval times
Steps To Reproduce
./opa bench --data issue_case_1.rego 'data.issue.operation_exists'
./opa bench --data issue_case_2.rego 'data.issue.operation_exists'
issue_case_1.txt
issue_case_2.txt
Expected behavior
Performance should be equivalent in issue_case_1 & issue_case_2
Additional context
The iteration here is a fairly complex type of
map<string, set<tuple<string, string>>>
The text was updated successfully, but these errors were encountered: