Open davidmarne-wf opened 4 months ago
Good find!
Looking at the output from the compiler (using opa-explorer), the nested iteration is left intact, while the some .. in
loops are rewritten to something like this:
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 some .. in
iteration and rewrite them to a single nested iteration where possible.
(btw, I think "more performant" should be "less performant" in the description 🙂)
I can confirm that evaluation of the "short-form" enumeration role_allowed_operations[_][operation]
is slightly different, and it' wouldn't surprise me if this has a performance impact.
As @anderseknert suggests, I think it should be possible to detect this at compile-time (at least trivial cases), and optimize accordingly.
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.
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>>>