Closed bk2204 closed 1 year ago
I don't think the realloc is necessary in the Vec<u8>
-> Bytes
conversion, since a Bytes
can be subsliced.
The details aren't fresh in my mind, but I think the reason it does into_boxed_slice is because there was no room to store the length and capacity.
I think this can be pretty easily implemented by turning the Vec<u8>
into a shared variant. If folks want a patch, I'm happy to send one, and I've even added a few tests.
Making it shared does require a new allocation too. Would it be worth checking if the length and capacity are the same, and so into_boxed_slice won't need to shrink?
That's true, but it requires a much smaller allocation of a handful of bytes, which I think will be acceptable here. Reallocating my buffer of 64 KiB requires substantially more space and a much larger memcpy
as well.
I can certainly see if the length and capacity are the same and use into_boxed_slice
. However, in my case, it's definitely not.
When converting a
BytesMut
intoBytes
viafreeze
, the operation can cause a re-allocation to occur because we callinto_boxed_slice
. This is unacceptable in some hot codepaths.The documentation says that “[t]he conversion is zero cost.” I don't believe that an allocation can be considered zero cost.
Example code:
If you compile this program and set a breakpoint on
realloc
, you'll see this (after the startup code):I believe in this case that's because the variant of the
BytesMut
isKIND_VEC
and we're then recreating theVec
and doing aninto
, which callsinto_boxed_slice
. This is also the case if one substitutesBytesMut
in the code forVec
, but in that case, there's no guarantee of that being zero-cost.I'm not sure what the best way forward here is, but it would be great if someone could propose an idea where this really is zero cost. I have a server where I need to read some data into a buffer and then transfer it using a Bytes via Hyper, and since this is a very hot codepath, I really want to avoid a reallocation, since the reallocation shows up in my performance graphs.