Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork1.7k
optimization:ReverseChunks::next,LinesChunkBuffer::fill andBytesChunkBuffer::fill intail#9667
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
GNU testsuite comparison: |
sylvestre commentedDec 16, 2025
thanks did you run hyperfine with your version, the previous and the gnu impl to compare the results? |
fereidani commentedDec 16, 2025
@sylvestre Sure I will send the PR. |
Hi,
First of all, I'm really happy that this project came together!
Here are a few improvements I identified and implemented:
For
ReverseChunks::next, the original implementation allocated a new buffer on every call tonext(), which was quite expensive. I changed it to use a preallocatedVec<u8>that is zero-filled on each iteration whenself.block_idx > 0.a same optimization was applied to
BytesChunkBuffer::fillandLinesChunkBuffer::fill. In the previous version, the linechunk = self.chunks.pop_front().unwrap();dropped a perfectly reusableBoxon every loop iteration. I removed the unnecessarychunk.clone(), transferred ownership of the existing value back into the chunks container, and switched to usingOption<Box<Chunk>>. This allows us to reuse the allocation when the first chunk is removed, eliminates the need for new allocations in most cases.Let me know if you'd like to discuss any of these in more detail!