3 ms·
For what it's worth, if you want the best performance out of Serde you have to use from_str or from_slice, regardless of if you pass a BufRead to it. https://g
by sitta 5y ago
For what it's worth, if you want the best performance out of Serde you have to use from_str or from_slice, regardless of if you pass a BufRead to it.
https://github.com/serde-rs/json/issues/160 https://github.com/serde-rs/json/issues/160
- scottlamb 5y agoIn that issue, they're talking about specialization. With that language feature, they'd be able to make this interface optimal for either mode: * if the caller supplies a BufRead, they can use fill_buf. * if the caller supplies a Read that isn't BufRead, they can wrap it in a BufReader or the like, and then use fill_buf on that. Stable Rust doesn't have specialization today, so at most one of those can be handled optimally. (It looks like neither of them is handled well at all right now.) Maybe they're designing the simplest possible API for post-specialization. They might have been a lot more optimistic when they chose it than I am now about when Rust will get specialization. Or they might be heavily prioritizing API stability for years. Right now this interface is what I would call an attractive nuisance, leading to the problem in this blog post. What I would do for today is to have a method that explicitly takes a BufRead and uses it appropriately. And then perhaps a convenience method that explicitly wraps a Read in a BufRead. And the caller chooses. I'd deprecate the attractive nuisance interface for now (maybe reversing that later).