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

Export BytesMut::from_vec(vec) #615

Open
al8n opened this issue May 28, 2023 · 4 comments
Open

Export BytesMut::from_vec(vec) #615

al8n opened this issue May 28, 2023 · 4 comments

Comments

@al8n
Copy link

al8n commented May 28, 2023

Hi, can we expose BytesMut::from_vec? Which can help avoid copying when building a BytesMut from Vec<u8>

@al8n al8n changed the title Expose BytesMut::from_vec(vec) Export BytesMut::from_vec(vec) May 28, 2023
@rklaehn rklaehn mentioned this issue Apr 9, 2024
@Darksonn
Copy link
Contributor

That seems reasonable to me. We can add it as a From impl.

@braddunbar
Copy link
Contributor

The comments on from_vec call out the fact that the allocation strategy may change at some point, making this a more expensive operation because it would then involve a copy. I'm not sure how likely that is and I don't have any opinions about exposing it, but I wanted to call it out here since this would be a departure from that stance.

bytes/src/bytes_mut.rs

Lines 824 to 829 in 327615e

// For now, use a `Vec` to manage the memory for us, but we may want to
// change that in the future to some alternate allocator strategy.
//
// Thus, we don't expose an easy way to construct from a `Vec` since an
// internal change could make a simple pattern (`BytesMut::from(vec)`)
// suddenly a lot more expensive.

@Darksonn
Copy link
Contributor

Yes, good point, thanks.

@hackerbirds
Copy link

hackerbirds commented Jun 22, 2024

While it's true that the allocation behind Bytes could change in the future and suddenly make the conversion slower, as a regular user who just needs to work with libraries using Bytes, I don't think it's a good decision to not have a From<Vec<u8>> implementation.

Some libraries use Bytes, others use Vec<u8>, and right now the easiest way I found to convert from a Vec<u8> into Bytes is to deref it into &[u8], and then use From<&[u8]>, which calls to_vec() internally and makes a clone/copy anyway. Given that there is no real other choice (at least to my knowledge, feel free to tell me if there's a better way), I suspect this is what most users also end up doing.

I don't see how that's any better than letting us have a From<Vec<u8>> which would be faster at least today, even in the future where this operation ends up slow. Sometimes we just have no choice to convert back and forth between the types to use foreign libraries. If the sudden performance hit really a concern, then perhaps let from_vec public instead of making a From, and document its behavior publicly (and not privately).

EDIT: Meant BytesMut, sorry.

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

No branches or pull requests

4 participants