perf: precompute json import sorted order#871
Open
He-Pin wants to merge 1 commit into
Open
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
.jsonimport 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:
Materializer.computeSortedInlineOrder(keyArray, memberArray)while constructing strict JSON import objects.Benchmark Results:
191.107 msmean vs candidate180.272 msmean.218.687 msmean vs clean273.169 msmean../mill --no-server --ticker false --color false __.reformatand./mill --no-server --ticker false --color false -j 1 __.testpassed; full test run reported passing suites including444/444,511/511, and457/457platform 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.