Re: Capy review

On Tue, 30 Jun 2026 at 01:46, Peter Dimov via Boost <[email protected]>
wrote:

> Ruben Perez wrote:
> > My use case (length-prefixed message protocols) looks like a good use
> case for
> > capy::read (plain buffer version). Actually, the reference section lists
> this use
> > case as example [18]. I'm not sure this pattern is efficient, though, as
> with
> > most streams in Corosio you'd be running two syscalls per message. As an
> > improvement, I could implement a wrapper stream that buffers bytes (à la
> > Asio's buffered_stream [19]), but manual handling looks simpler to me.
>
> Buffered streams are absolutely essential for performance when serializing
> or deserializing (e.g. over binary protocols), see
>
> https://github.com/pdimov/corosio_protocol_bench



They are if you mix deserialization and reading like in your benchmarks. My
experience doing this has been negative for a number of reasons. Since all
the protocols I implement have the notion of messages (length prefixed), I
read at least one message into a resizable buffer, then deserialize it.
Most of the times, you actually read more than one message, so my primitive
would be something like

read_some_messages(Stream&, Buffer&) -> range of message

Which is somehow handling the buffering myself, rather than using
buffered_stream explicitly.

This is also why I'd find the read_at_least function that you proposed in
Slack useful. Although I can live without it.
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/ZP7MYPH7YTJMCKWQKVRXR7N5HQS4UNNE/