mirror of
https://github.com/open-policy-agent/opa.git
synced 2026-08-15 12:52:44 -06:00
Anders Eknert
4c13c6cc9f
Funnily, this started out as an attempt to look into issues reported with compiling large policy sets... before I realized that it isn't likely *this* compiler that has perf issues, but the one that "compiles" bundles as part of activation. So while these fixes likely does little to address that, there are still some rather nice improvements here, where the big ones as ususal are mostly just wins from avoiding work where it's possible. For benchmarking I've used Regal's embedded bundle, which isn't great to use over time, as it's a moving target. But since it's a pretty extensive bundle and one that covers most features of OPA, it's at least good for 1:1 comparisons when testing perf improvements. ``` // 66555594 ns/op 50239492 B/op 1083664 allocs/op - main // 62569440 ns/op 38723015 B/op 944277 allocs/op - compiler-optimizations pr ``` The B/op / alloc_space improvement is particularly nice here. What's noteworthy is how relatively little impact that has on performance in this case. That may be surprising but aligns pretty well with my previous experience of Go code where a lot of time is spend in recursive walks — that simply takes time, no matter how much you optimize. Oh well, less memory allocated for this is more memory to spend elsewhere. (I'm adding the benchmark used below to Regal in a parallel PR) Signed-off-by: Anders Eknert <anders@styra.com>