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

Consider using a pointer offset instead of a slice and integer position #210

Open
jdm opened this issue Dec 8, 2017 · 4 comments
Open

Comments

@jdm
Copy link
Member

jdm commented Dec 8, 2017

The generated assembly for code using next_byte_unchecked like skip_whitespace has a suprising number of indirections in order to actually get the byte value. This is caused by the need to get the slice, then get the byte at the desired offset from it at

self.input.as_bytes()[self.position + offset]
. If we use store a pointer and increase its instead of the offset, it should cause more efficient code to be generated.

@SimonSapin
Copy link
Member

A safe way to represent a slice as a pair of pointer might be std::slice::Iter.

@pickfire
Copy link

Is next_byte_unchecked really unchecked and free of bound checks? I thought we need to use unsafe get_unchecked or assert bounds to do that?

@emilio
Copy link
Member

emilio commented Aug 11, 2020

It's unchecked in the sense that it doesn't check for EOF. But it does a bounds-check / panics if you misuse it.

emilio added a commit that referenced this issue Apr 7, 2024
…king.

Fixes #210. Posted for posterity since it seems a regression at least in
some of our benchmarks, and would need more work.
emilio added a commit that referenced this issue Apr 7, 2024
…king.

Fixes #210. Posted for posterity since it seems a regression at least in
some of our benchmarks, and would need more work.
@emilio
Copy link
Member

emilio commented Apr 7, 2024

Posted #381 for posterity which uses a slice iterator. It seems that's a regression at least on the big-data-url test, so it'd need more work.

emilio added a commit that referenced this issue Apr 7, 2024
…king.

Fixes #210. Posted for posterity since it seems a regression at least in
some of our benchmarks, and would need more work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants