Skip to content

perf: precompute json import sorted order#871

Open
He-Pin wants to merge 1 commit into
databricks:masterfrom
He-Pin:perf/json-import-sorted-order
Open

perf: precompute json import sorted order#871
He-Pin wants to merge 1 commit into
databricks:masterfrom
He-Pin:perf/json-import-sorted-order

Conversation

@He-Pin
Copy link
Copy Markdown
Contributor

@He-Pin He-Pin commented May 23, 2026

Motivation:
Strict JSON imports produce immutable object trees with fixed keys. On kube-prometheus rendering, computing sorted inline order lazily for imported JSON objects appeared in profiling as avoidable render-time work.

Key Design Decision:
Only strict .json import objects with more than one key eagerly cache _sortedInlineOrder. These objects are built from fixed key/member arrays, reject duplicate keys earlier, and are published through the parse cache after construction, so eager sorted-order computation is semantically equivalent to the existing lazy render-time computation.

Modification:

  • Precompute Materializer.computeSortedInlineOrder(keyArray, memberArray) while constructing strict JSON import objects.
  • Preserve the existing single-key/default path.
  • No changes to Jsonnet object evaluation semantics or non-JSON imports.

Benchmark Results:

  • Scala Native kube-prometheus A/B, same-run against clean baseline:
    • Forward: clean 191.107 ms mean vs candidate 180.272 ms mean.
    • Reverse: candidate 218.687 ms mean vs clean 273.169 ms mean.
  • Local validation: ./mill --no-server --ticker false --color false __.reformat and ./mill --no-server --ticker false --color false -j 1 __.test passed; full test run reported passing suites including 444/444, 511/511, and 457/457 platform groups.

Analysis:
This moves deterministic sorting work from the hot render path into the strict JSON import construction path, where the object content is already known and immutable. It avoids touching general object evaluation, object comprehensions, or dynamic Jsonnet object behavior.

References:

Result:
Less render-time work for strict JSON imports while preserving output equality and compatibility.

Motivation:
Strict JSON imports produce immutable object trees with fixed keys. Rendering these imported JSON objects currently computes the sorted inline order lazily on first render, which shows up on realworld kube-prometheus output.

Modification:
When building strict JSON import objects with more than one key, precompute _sortedInlineOrder before publishing the cached object. Single-key objects keep the existing lazy/default path.

Result:
The cached JSON import object carries the same sorted order that rendering would compute later, reducing repeated render-time work without changing Jsonnet semantics.
@He-Pin He-Pin marked this pull request as ready for review May 23, 2026 18:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant