Stéphane Lavergne

That's not possible, since the length of a block is written before its data and is itself encoded as a Varint. This is why the current implementation encodes recursively and...

I like this idea, although I think here it would not be ideal: * Preallocating a buffer of sufficient size would be tricky to get right without doing the `Bin_prot`-style...

With deep structures of messages (as I will deal with), I believe the difference can be significant. Again, this idea presupposes computing sizes exactly once, not multiple times. There's no...

I haven't landed on a solution for that yet. This issue is a back-burner brainstorm for me, not something I'm implementing this week. (Things like Yojson support for Protobuf `map`...

@c-cube I really like that stack which relies on a deterministic traversal order. A kind of `int Buffer.t` would've been neat for this. I assume you'd do something similar to...

I don't understand the buffer recycling idea. If there was a pool of buffers, sure there'd be a few less allocations (less calls to `Buffer.create`) but there'd be just as...

Doesn't writing backwards require having a big enough buffer to begin with? Or do they resize periodically like `Buffer` does, except at the head instead of the tail?

Yes, I _really_ like that idea. I can't think of other uses to having a sizing function besides actually encoding, so if we can avoid it entirely we should. It...

It might be trivial to even eliminate that final alloc+blit for users who don't want it. For example if the new "from-the-end" internal buffer used a `bigstring` internally (could make...

Yes, returning the data storage and the offset instead of blitting would be nice to have as an option. I'll still need to blit _that_ into a `bigstring` for some...