-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add read_to_end implementation to &[u8]'s Read impl #45083
Conversation
This looks good to me. Only a super minor curiosity, does it matter to us where the slice's pointer is when read_to_end returns? The remaining slice here points into a static |
I was briefly wondering the same thing and then I somehow got distracted and forgot. I guess it makes sense to set |
I don't think anyone would run into issues in practice with the current implementation, but switching to |
The default impl for read_to_end does a bunch of bookkeeping that isn't necessary for slices and is about 4 times slower on my machine.
dda3d07
to
d52acbe
Compare
I've changed the implementation. The method now sets |
Thanks! @bors r+ rollup |
📌 Commit d52acbe has been approved by |
Add read_to_end implementation to &[u8]'s Read impl The default impl for read_to_end does a bunch of bookkeeping that isn't necessary for slices and is about 4 times slower on my machine. The following benchmark takes about 30 ns before this change and about 7 ns after: ``` #[bench] fn bench_read_std(b: &mut Bencher) { let data = vec![0u8; 100]; let mut v = Vec::with_capacity(200); b.iter(|| { let mut s = data.as_slice(); v.clear(); s.read_to_end(&mut v).unwrap(); }); } ``` This solves the easy part of rust-lang#44819 (I think extending this to `Take<&[u8]> `would require specialization)
The default impl for read_to_end does a bunch of bookkeeping
that isn't necessary for slices and is about 4 times slower
on my machine.
The following benchmark takes about 30 ns before this change and about 7 ns after:
This solves the easy part of #44819 (I think extending this to
Take<&[u8]>
would require specialization)