-
Notifications
You must be signed in to change notification settings - Fork 567
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
Implement RawValue type #480
Conversation
Awesome! Thank you. 👍 |
serde_json::from_str::<Wrapper>(r#"{"a": 1, "b": {"foo": 2}, "c": 3}"#).unwrap(); | ||
assert_eq!(r#"{"foo": 2}"#, wrapper_from_str.b.as_ref()); | ||
|
||
let wrapper_from_reader = serde_json::from_reader::<_, Wrapper<'static>>( |
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.
This is a compiler bug, this line shouldn't compile. I filed rust-lang/rust#54302 to follow up. Still thinking about what that means for how we want to expose RawValue.
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.
Hah, of course, not sure what I thought this would do!
Does that mean we might want to have an owned and a borrowed variant of RawValue
?
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.
I believe so. I opened #485 to experiment with that design. Let me know what you think.
The way |
Ah, I was looking for an explanation like that, might be worth adding a code comment to make this clear to anyone coming across this in the future. As I said on the other PR (#485), do let me know if I can help move this forward in any way! |
Implements the
RawValue
type described in #355. On this benchmark, using theRawValue
type instead of deserializing/serializing viaValue
results in a 3-4x speed-up.I did not adhere fully to the way that the existing arbitrary precision feature is implemented, because I found it easier to use newtypes rather than structs to pass the raw data back and forth. If you want, I'm happy to either change it so that it uses the same approach as the arbitrary precision feature, or to change the arbitrary precision feature to use this (imo) simpler approach.
In the documentation for
RawValue
I mentioned two important caveats which apply for this implementation:RawValue
will retain its original formatting and will not be minified or pretty-printed.RawValue
can not be used with the#[serde(flatten)]
attribute, as it relies on the original input buffer.What you described in #323 might be a cleaner solution to these problems, but it also sounds more complex and resource hungry (using 4x-8x the amount of memory).
Let me know what you think!