4 ms·
I wonder why FlatBuffers aren't a more popular option[0]. The format isn't even mentioned in the article. I have never used it (since I my needs were not that a
by vanderZwan 8y ago
I wonder why FlatBuffers aren't a more popular option[0]. The format isn't even mentioned in the article. I have never used it (since I my needs were not that advanced), but it seem to combine quite a few amazing qualities of other serialization formats, while adding a few of its own. It even has a version without a schema called "FlexBuffers"[1]. I would expect anyone considering ProtoBuffers and MsgPack to give FlatBuffers a look.
Two five minute lightning talks by Van Oortmerssen, who created the format (another reason to take a closer look IMO), that shows off some of the powerful features:
Lightning Talk: FlatBuffers (2015)
https://www.youtube.com/watch?v=olmL1fUnQAQ https://www.youtube.com/watch?v=olmL1fUnQAQ
Going Further with FlatBuffers
https://www.youtube.com/watch?v=90ND0yQVYg8 https://www.youtube.com/watch?v=90ND0yQVYg8
[0] https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/
[1] https://google.github.io/flatbuffers/flexbuffers.html https://google.github.io/flatbuffers/flexbuffers.html
- vvanders 8y agoI've used it in production, can confirm it is awesome. Flatbuffers destroys ProtoBuf both in terms of allocations(1 vs N where N is usually huge) and deserialization speed. You also get explicit control over your data layout in memory when you write the message. So if you know what your read patterns are up-front you can get amazing cache usage even in managed languages.