Support zero-allocation encoding into user-provided containers (for compatibility with runtimes like Monoio)

[hey-researcher]

It would be very helpful to have the ability to encode data directly into a user-provided, owned container, rather than being limited to buffer.encode(…) -> &'_ [u8].

Reasoning:
Some async runtimes, such as monoio, require owned containers for I/O operations. Currently, code like the following does not work because buffer.encode returns a borrowed slice:

let data = buffer.encode(&my_data);
let (res, _) = socket.send(data).await;

It would be ideal if the API allowed encoding directly into a user-provided buffer, for example:

let mut my_buf = Vec::with_capacity(1024);
…
bitcode::encode_to(&my_data, &mut my_buf);
let (res, ret_my_buf) = socket.send(my_buf).await;
my_buf = ret_my_buf;

[finnbear]

Hello; have you considered/benchmarked either of these solutions?

1. let my_buf = buffer.encode(&my_data).to_owned(); (if you can afford an allocation)
2. my_buf.clear(); my_buf.extend_from_slice(buffer.encode(&my_data)); (if you can afford a copy)

FWIW, the simplest way we could add support would be Buffer::out_mut(&mut self) -> &mut Vec<u8> which you could std::mem::take after a call to the existing Buffer::encode followed by *Buffer::out_mut(&mut self) = ret_my_buf;.

[hey-researcher]

Hello,

1. let my_buf = buffer.encode(&my_data).to_owned(); — would be exactly bitcode::encode(…)
2. yes, but not always.

the simplest way we could add support would be…

sounds good

I tried something like that:

  pub fn encode_to<T: Encode + ?Sized>(&mut self, t: &T, out: &mut Vec<u8>) {
    // Safety: Encoders don't have any lifetimes (they don't contain T either).
    let encoder = unsafe { self.registry.get_non_static::<T::Encoder>() };
    encoder.reserve(NonZeroUsize::new(1).unwrap());
    encode_inline_never(encoder, t);
    out.clear();
    encoder.collect_into(out);
  }

a little bit messy, but worked

[finnbear]

1. bitcode::encode is slower than buffer.encode(&my_data).to_owned() because the former has to:
   • allocate the encoder machinery (i.e. lots of Vec-like objects corresponding to each field/sub-field in your datastructure), whereas the latter caches it (Vec<u8> is only one of two fields in Buffer).
   • grow the output Vec<u8> from small to large, re-allocating each time, rather than starting with an empty output Vec<u8> of approximately the right capacity.
2. I recommend using this workaround for now. We might add an API that removes the need for this additional copy, but will likely wait for additional demand for it (to outweigh the cost of complexity and more-or-less exposing a Buffer implementation detail).