optimize for protos containing large blobs

[rajatgoel]

One small optimization prost can do for proto message containing large blobs is - specialize decoding protobuf from reference counted buffers and give a reference to a slice of the underlying buffer as bytes instead of copying them. Similarly, when encoding the message simply chain these big blobs instead of copying them to output buffer. I think the C++ does this optimization for all bytes fields that specify ctype=cord.

[danburkert]

There's no support for this yet, but it should be possible to add. The 'plan' is to:

• Add an option to prost_build::Config to output string and bytes fields as bytes::Bytes instead of String and Vec<u8>.
• Add specialization into the decoding stack so that when decoding into a bytes::Bytes field from a bytes::Bytes source, it does a shallow copy (bytes::Bytes is ref-counted).

This solution unfortunately isn't too general - it only works with types known to prost through explicit specializations, but I think bytes::Bytes will cover the majority of cases. Perhaps if there's a rope data structure that gains prominence down the road that could be added too.

[nerdrew]

Has anyone started on this? What does "specialization in the decoding stack" look like?

[vorner]

Looking at it, using Bytes instead of String feels a little wrong, doesn't it? I mean, something that checks the unicode and derefs into &str would be nice.

Or is the plan to provide some wrapper?

[quininer]

@vorner I think String<Bytes> is what you want.

[nrc]

Using Bytes for bytes would be useful for small bytes fields too - at the moment we spend a huge amount of time allocating small Vecs for such fields. Being able to reference the underlying buffer, or even allocate a large slab of memory once would be a big performance win.

[mzabaluev]

As a container for string buffers backed by Bytes, I have published the strchunk crate.

[vorner]

What is the advantage of using that over that String<Bytes> thing above?