Comment by reactordev
8 months ago
Oh it’s worse, it’s a full on marshal of the whole data. What we need is a no-allocation-protobuf that binds to existing memory, knows about aliases, can deal with a pointer. I love protobuf but I’ve moved to other messaging implementations that provide a faster marshal/unmarshal. Maybe I’ll give this a try.
Flatbuffers from Google is 11 years old and does that. (Protobufs is over 20 at this point).
https://stackoverflow.com/questions/25356551/whats-the-diffe...
MessagePack is what I’m currently using, I needed a small binary format.
It's not out-of-the-box compatible with everything in the way that `proto3` is, but if dealing with the really atrocious performance and ergonomics of protobuf in C++ (among other targets) is bad enough to warrant going slightly off the beaten path, flatbuffers is still pretty mainstream. It's got bindings for the big languages and it's used IIRC in a bunch of the FAANG mobile clients, stuff like that.
Going a little further afield, `capnp` is cool. It's got a much nicer IDL and object model, but you start to get into where non-C++ bindings are "community maintained" in a pretty loose sense. I'm not sure how much sense it makes unless it really lands on your polyglot stack perfectly, because if you only need C++, zpp_bits is really ergonomic and approaches theoretical limits on performance along a number of dimensions.
I don't love any of the answers here.
I’m currently using MessagePack. It does the job of making small binary messages but I still suffer from marshal/unmarshal copying.
For certain messages with a fixed size (no strings or arrays) I can pin a message and reuse its memory address within the queue but there’s still data in memory that needs to be copied. At the very least from the TCP/IP stack.