One thing about google proto is that, at least in many languages, every message throws off a ton of garbage that stresses the GC. On the send side, you can obviously re-use objects, but on the receive side no.
This is also because Google's Protobuf implementations aren't doing a very good job with avoiding unnecessary allocations. Gogoproto is better and it is possible to do even better, here is an example prototype I have put together for Go (even if you do not use the laziness part it is still much faster than Google's implementation): https://github.com/splunk/exp-lazyproto
More and more languages are being built on top of the "upb" C library for protobuf (https://github.com/protocolbuffers/upb) which is designed around arenas to avoid this very problem.
Currently Ruby, PHP, and Python are backed by upb.
Disclosure: I work on the protobuf team, and created the upb library.
Agreed but please do something about Go.
Re:Cap'n Proto 1.0
by cmrdporcupine on Friday July 28, 2023 @01:47PM
(#36910524)
I've always been excited about zero copy messages in the context of its potential in database systems; the thought of tuples working their way all the way from btree nodes in a pager, to query results on the network without copies seems fantastic.
But every time I've tried to prototype or implement around this model I've run into conceptual blocks. It's a tricky paradigm to fully wrap one's head around, and to squeeze into existing toolsets.
That said I personally have always been much more excited about the RPC protocol than the serialization. I think the RPC protocol is actually a paradigm shift for almost any non-trivial use case.