-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
switch the json backend to json-iterator #19
Conversation
@neolit123: GitHub didn't allow me to request PR reviews from the following users: stealthybox, errordeveloper. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
// Marshal marshals the object into JSON then converts JSON to YAML and returns the | ||
// YAML. | ||
func Marshal(o interface{}) ([]byte, error) { | ||
j, err := json.Marshal(o) | ||
j, err := caseSensitiveStrictJSONIterator.Marshal(o) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smarterclayton, didn't you see performance regressions in json-iter marshaling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would they really be relevant for YAML encoding? It's not that we do that in critical paths, do we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this doesn't affect all of YAML code paths in the current form.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw json-iterator isn't fully compatible with the standard library right now, created json-iterator/go#371. PTAL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
json-iterator/go#371 has merged.
Thanks for making these changes! LGTM Is there anything we can do to help get this merged? :) |
Hey @neolit123, as Martina said - we'd be happy to help :) |
@errordeveloper up to the reviewers at this point. :) |
Ref: kubernetes/kubernetes#70574 (comment), kubernetes/kubernetes#63242 (comment) The second PR referenced above did have high allocations: Running On k/k master right now:
k/k right now with changes in the second PR (kubernetes/kubernetes#63242):
k/k with changes in this PR:
So it should probably be fine... |
You should also run the serialization benchmarks in pkg/api/testing/serialization_test.go to get a before and after round trip time (that tests several variants of objects, whereas BenchmarkGet tests a single known object). |
Running existing benchmarks (before and after) yielded similar results...but that isn't surprising because none of the benchmarks actually look for yaml marshaling and unmarshaling. Created kubernetes/kubernetes#78688 for adding benchmarks for yaml marshaling and unmarshaling as well. Using these benchmarks, incorporating changes in this PR into k/k yield higher allocations... :( Running Before:
After:
|
What is the underlying goal of this PR? Use json-iterator because ? Consistency with Kube is important, but it's not all. Was there a discussion about the why? I don't see many comments in #17 |
/assign @smarterclayton |
/unassign |
here is an example of this problem in the wild: kubeadm has strict unmarshaling to show warnings and then perform regular unmarshall (two pass). |
so going back to the OP and the discussion there are at lease 3 concerns here:
we enabled strict unmarshal in this library not so long ago, and given strict unmarshal is optional it seems that this might not affect that many users. but this is still probably going to break someone, somewhere once they move to the latest SHA of this repository.
not sure if this will break anyone, probably not. i will update this PR and leave it for a couple of more weeks. |
722a658
to
652a983
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: neolit123 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
add a couple of json interator configurations: 1) jsonIterator should be compatible with the old encoding/json there is a breaking change here because the "JSONOpt" is now a no-op, although the options in encoding/json are not very useful. 2) caseSensitiveStrictJSONIterator is compatible with econding/json WRT to DisallowUnknownFields, but it also has CaseSensitive. This is a breaking change for strict unmarshal users that previously allowed case-insensitive fields. Something else to note is that json-iter does not seem to tolerate field keys called "true", which the one from stdlib does. Unit tests had to be adapted because of that. Other changes: - add a new public method UnmarshalWithConfig that allows passing a json-iter configuration - update/add unit tests - update go.mod/sum - remove yaml_go110*.go These files had the purpose to handle DisallowUnknownFields for json.Decoder which is no longer needed.
652a983
to
d8dcdb8
Compare
clearing some pending PRs from my backlog. |
we are seeing more cases of this in the wild: |
add a couple of json interator configurations:
jsonIterator should be compatible with the old encoding/json
there is a breaking change here because the "JSONOpt" is now
a no-op, although the options in encoding/json are not very useful.
caseSensitiveStrictJSONIterator is compatible with
econding/json WRT to DisallowUnknownFields, but it also has
CaseSensitive. This is a breaking change for strict unmarshal users
that previously allowed case-insensitive fields.
Something else to note is that json-iter does not seem to tolerate
field keys called "true", which the one from stdlib does.
Unit tests had to be adapted because of that.
Other changes:
a json-iter configuration
These files had the purpose to handle DisallowUnknownFields for
json.Decoder which is no longer needed.
/kind feature
/priority important-longterm
fixes #17
fixes #15
/assign @dims
/cc @sttts @errordeveloper @stealthybox
/hold