[alfalfasprout]

Been using flatbuffers in production for a high speed market feed for a month now. Love it. Decode/encode time is absurdly fast (~1-2 microseconds for a small to medium schema). If you're pushing 50k+ events/second it can be a great choice. Takes up almost no space on the wire too.

[amluto]

Try Cap'n Proto instead. Better designed and faster.

[RyanZAG]

Faster? To quote the author of Cap'n Proto:

> 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."

[0xmohit]

Kenton Varda (the author of Cap'n Proto), was the primary author of Protocol Buffers version 2.

Quoting from https://capnproto.org/index.html

  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.

[euyyn]

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 :)