multiaddr: Replace Bytes with Arc<Vec<u8>>.

[twittner]

CC: #1367, #1351

[tomaka]

What about Arc<[u8]> instead? This needs a bit more efforts, but we remove one indirection.

[burdges]

Just curious: What's wrong with Bytes? I forgotten it but vaguely recall it attempting to do some things nicely.

[twittner]

What about Arc<[u8]> instead? This needs a bit more efforts, but we remove one indirection.

I think that resizing complicates this approach. It would probably require quite a bit of effort to reach the same level of efficiency as with Bytes or Arc<Vec<u8>>. If we do not want to pay for the Vec<u8> allocation, maybe it is best to keep the current bytes v0.4 implementation?

Just curious: What's wrong with Bytes? I forgotten it but vaguely recall it attempting to do some things nicely.

Compared to previous versions, in v0.5 the design of Bytes lends itself more strongly to immutable usage. In particular Bytes::try_mut has been removed and we made use of it to efficiently modify Multiaddr values which are not shared.

[tomaka]

Small nit: I'm extremely paranoid when it comes to the Write trait.
Writing to a &mut Vec<u8> automatically extends the vector, while writing to a &mut [u8] will return an error if there isn't enough space.
Because of that, I'd prefer to make explicit that we're writing to a &mut Vec<u8>.

[tomaka]

Let's wait for #1328 before merging!

[mxinden]

Do I understand correctly that we have the following 4 options that only differ in performance?

• Keep using bytes 0.4.

• Switch to bytes 0.5 having to clone a BytesMut.

• Use Arc<Vec<u8>>.

• Use Arc<[u8]>.

If so, before introducing this change set, shouldn't it include benchmarks? Am I missing something?

[twittner]

Do I understand correctly that we have the following 4 options that only differ in performance?

• Keep using bytes 0.4.
• Switch to bytes 0.5 having to clone a BytesMut.

This second option would not provide much benefit over a Vec<u8> as BytesMut will copy on clone.

• Use Arc<Vec<u8>>.
• Use Arc<[u8]>.

If so, before introducing this change set, shouldn't it include benchmarks? Am I missing something?

The last option has not been implemented. I welcome all benchmarks but the change is not really about improving the performance over what we have now but motivated by the desire to remove a now outdated dependency (bytes v0.4). In #1353 I left parity-multiaddr as is because I would be fine with keeping it as an implementation detail, but since #1351 is still open, there seems to be a need to get rid of it.