Zero copy or zero alloc optimization?

[ileixe]

Hi,

We've invested the feasibility to replace our hand-write binary interpretation, and want to ask some of optimization technique.

  #[bitfield]
  #[binrw]
  #[br(map = Self::from_bytes)]
  #[derive(Default)]
  pub struct ProgramHeader {
      version: B4,
      protocol: B4,
      flags: u8,
      // Number of Op.
      count: u16,
  }


  #[repr(C)]
  #[binrw]
  #[brw(little)]
  #[derive(Default)]
  pub struct Program {
      header: ProgramHeader,
      #[br(count = header.count())]
      ops: Vec<Op>,
  }

This is our protocol layout and our concerns are

1. Zero alloc

Regarding this part,

 #[br(count = header.count())]
      ops: Vec<Op>

We've used Vector here and it makes me worried about decoding performance. Before, we just reads byte stream and uses Op inplace without collecting them via Vector.

I guess there might be no way to have variadic length of data without allocation, but want to ask owner's thought.

2. (Strict) Zero copy

Also, it's similar to previous concern. Can we have any chance to reduce copy? I know strict zero copy is only available via in-place transmute which requires somehow different binary encoding technique (e.g. rkyv), but still want to ask as well. We are affording some unsafety to some extent (We're embedded system anyway)

Thanks

(Lastly, I want to mention that even there's no such way, I would like to give weight for this crate because of much better usability, so please interpret this issue to seek little possibility.)

[csnover]

Hi, thanks for your question! Happy to hear that you are enjoying using binrw.

binrw is not a zero-copy library and it can’t be because it operates on streams, not raw memory. If your data is already in memory and you are willing to transmute, zero-copy crates will be significantly faster at parsing. The only performance advantage binrw can ever really offer over a zero-copy library is that it generates normal Rust structs which may be optimised by the compiler for your platform, and thus may be faster when used within the rest of the application, but #[repr(C)] eliminates at least some of that capability, so don’t do that. :-)

In this situation, you may want to perform partial parsing instead of reading everything up front. In other words, read only the ProgramHeader from the stream, then parse individual Op from the stream on demand, instead of immediately collecting all Op into a Vec. Then you can control how many Op are parsed at once and avoid any potentially unbounded allocations.

If you are also parsing enums and are concerned about allocation overhead you may also want to turn off error collection with #[br(return_unexpected_error)], since storing enum variant errors requires allocating memory even if they are discarded later.

Hope this helps!

[ileixe]

Hi @csnover . Thanks for the answer! (Sorry for late response, I did not get notification)

In this situation, you may want to perform partial parsing instead of reading everything up front. In other words, read only the ProgramHeader from the stream, then parse individual Op from the stream on demand, instead of immediately collecting all Op into a Vec. Then you can control how many Op are parsed at once and avoid any potentially unbounded allocations.

This is interesting, but It's bit unclear to me how to achieve via binrw API. (and I wonder it can be zero alloc with inplace interpretation) Can you give small example?

Thanks!

[csnover]

Just delete ops: Vec<Op>, and then when you need to read an Op, call Op::read:

let header = ProgramHeader::read(&mut stream)?;

for _ in 0..header.count {
  let op = Op::read(&mut stream)?;
  do_thing_with_op(op);
}

There will be no data allocation as everything here is done on the stack.

[ileixe]

Oh, that's cool.

What about encoding part? From sender side, do we still have to encode Ops right after header, right?

[csnover]

I’m sorry, I don’t understand your question. If you have control over the protocol, then you can do whatever you want.

[ileixe]

Got it. Thanks!