mirror of
https://github.com/open-policy-agent/opa.git
synced 2026-08-12 19:32:48 -06:00
fc55be83e6
The `json.patch` built-in is quite versatile, and compared to patching via e.g. `object.union` et. al. often communicates intent better, IMO. But while it uses some fairly advanced logic for complex patch operations, it doesn't perform all that great on simple ones. This is a first and pretty basic attempt to improve that somewhat by picking the most low-hangig performance fruits, like avoiding repeated allocations of temporary term pointers. The main allocation source is the creation of EditTree's, and this remains a problem. I have created a sync pool but only managed to get the outermost edit tree to recycle, as I found it really hard to track where it's safe to release those created in the deeply nested calls. Additionally, I managed to trigger stack overflows trying to recycle child trees, so there seems to be some circular refs? Or I just did something wrong. If someone wants to look into this and pick up where I left, that'd be great! - Add InternedIntRange for testing, primarily - Intern keys used in json.patch patches - Clean up json.X built-in benchmarks - Reduce allocations in edit tree function - Avoid using intermediate data structures for JSON patches - Some unrelated interning fixes to reduce noise in tests and benchmarks (e.g. do less stuff in var inits) Selected benchmark that I used while working on this: **Before** ``` BenchmarkJSONPatchAddShallowScalar/object-10-16 147853 8008 ns/op 9667 B/op 206 allocs/op BenchmarkJSONPatchAddShallowScalar/array-10-16 201704 5889 ns/op 7256 B/op 173 allocs/op BenchmarkJSONPatchAddShallowScalar/set-10-16 182566 6733 ns/op 8103 B/op 156 allocs/op ``` **After** ``` BenchmarkJSONPatchAddShallowScalar/object-10-16 197414 6066 ns/op 7256 B/op 133 allocs/op BenchmarkJSONPatchAddShallowScalar/array-10-16 278121 4427 ns/op 5285 B/op 100 allocs/op BenchmarkJSONPatchAddShallowScalar/set-10-16 233884 4839 ns/op 6243 B/op 113 allocs/op ``` Signed-off-by: Anders Eknert <anders.eknert@apple.com>