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

Allow reclaiming the current allocation #686

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

Conversation

shahn
Copy link

@shahn shahn commented Mar 31, 2024

This is based on #680, where it was noted that it is hard to use BytesMut without additional allocations in some circumstances.

@shahn
Copy link
Author

shahn commented Mar 31, 2024

This is a draft to get some comments on whether such an API addition would be acceptable

This is based on tokio-rs#680, where it was noted that it is hard to use
BytesMut without additional allocations in some circumstances.
src/bytes_mut.rs Outdated Show resolved Hide resolved
@shahn shahn marked this pull request as ready for review April 7, 2024 12:22
src/bytes_mut.rs Outdated Show resolved Hide resolved
src/bytes_mut.rs Outdated Show resolved Hide resolved
src/bytes_mut.rs Outdated Show resolved Hide resolved
@braddunbar
Copy link
Contributor

braddunbar commented Apr 8, 2024

This looks a lot like BytesMut::reserve with the allocating parts cut out, which sounds a lot like a special case of BytesMut::try_reserve(ORIGINAL_CAPACITY). What would y'all think of a more general implementation in that vein?

@shahn
Copy link
Author

shahn commented Apr 8, 2024

I think it is hard to know what the original capacity is, generally, as it could've been influenced by lots of hidden operations before.
In addition, try_reclaim also doesn't move any bytes internally, with the goal of being very cheap to call. To me, the allocation behaviour of the entire crate is sometimes a bit hard to predict, so a separate function for it seems sensible

@braddunbar
Copy link
Contributor

I think it is hard to know what the original capacity is, generally, as it could've been influenced by lots of hidden operations before.

That's true, but presumably you know how much data you'll need to reserve regardless (otherwise dynamic allocation seems like the best strategy). So it doesn't particularly matter if you can reclaim the entire buffer, only if it can fit the data you're receiving. Or am I missing the point here?

In addition, try_reclaim also doesn't move any bytes internally, with the goal of being very cheap to call.

Very cheap relative to what though? Based on your description in #680, your only other alternative would be to allocate anyway, right? And that's definitely expensive relative to moving bytes. If that's not the alternative, what is?

@shahn
Copy link
Author

shahn commented Apr 8, 2024

My usecase is that I have a couple of BytesMuts and I would only allocate more memory for the current BytesMut if I couldn't reclaim the other. Basically, switch between the buffers, filling them up, while the data is processed on another thread. Once all the handles have been dropped I could reclaim the allocation and start filling the other buffer, etc.

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

4 participants