Skip to content
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

Avoid extraneous call to remaining in get_u8/i8 #490

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

guswynn
Copy link

@guswynn guswynn commented Mar 5, 2021

I have a chained datastructure that can dereference into a slice quite fast, but remaining requires walking the chain, which is relatively slow.

I would hazard a guess that this is the more common perf characteristic of non-contiguous impls of Buf.

Separately, this brings these impls in line with all the other get_ impls, which have a fast path with [u8].get(...), which does the same bounds check that I do in this patch

I think clippy will say to use non_empty, here, I think in this case this is more clear, but I will do whatever is preferred.

I have a chained datastructure that can dereference into a slice quite fast, but remaining requires walking the chain, which is relatively slow.

I would hazard a guess that this is the more common perf characteristic of non-contiguous impls of Buf. 

Separately, this brings these impls in line with all the other get_ impls, which have a fast path with [u8].get(...), which does the same bounds check that I do in this patch

I think clippy will say to use non_empty, here, I think in this case this is more clear, but I will do whatever is preferred.
@@ -285,7 +286,7 @@ pub trait Buf {
///
/// This function panics if there is no more remaining data in `self`.
fn get_u8(&mut self) -> u8 {
assert!(self.remaining() >= 1);
assert!(self.chunk().len() >= 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, the index bounds check happens just after this, I must assume these asserts are mostly to give a better panic message. Perhaps we could just make them debug_asserts?

@carllerche you added these asserts originally, I think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants