"With that said, my intuition is that SBE will probably edge Cap’n Proto and FlatBuffers on performance in the average case, due to its decision to forgo support for random access. Between Cap’n Proto and FlatBuffers, it’s harder to say. FlatBuffers’ vtable approach seems like it would make access more expensive, though its simpler pointer format may be cheaper to follow. FlatBuffers also appears to do a lot of bookkeeping at encoding time which could get costly (such as de-duping vtables), but I don’t know how costly.
For most people, the performance difference is probably small enough that qualitative (feature) differences in the libraries matter more."
Because it’s easy to pick on myself. :) I, Kenton Varda, was
the primary author of Protocol Buffers version 2, which is the
version that Google released open source. Cap’n Proto is the
result of years of experience working on Protobufs, listening
to user feedback, and thinking about how things could be done
better.
To be completely fair, Protobus v3 is also the result of years of experience working on Protobufs, listening to user feedback, and thinking about how things could be done better :)
> https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-...
"With that said, my intuition is that SBE will probably edge Cap’n Proto and FlatBuffers on performance in the average case, due to its decision to forgo support for random access. Between Cap’n Proto and FlatBuffers, it’s harder to say. FlatBuffers’ vtable approach seems like it would make access more expensive, though its simpler pointer format may be cheaper to follow. FlatBuffers also appears to do a lot of bookkeeping at encoding time which could get costly (such as de-duping vtables), but I don’t know how costly.
For most people, the performance difference is probably small enough that qualitative (feature) differences in the libraries matter more."