4 ms·

My go-to for needing to deserialize structured data in a fast way these days is flatbuffers[1]. It compacts nicely and more importantly is zero copy/allocation(

My go-to for needing to deserialize structured data in a fast way these days is flatbuffers[1]. It compacts nicely and more importantly is zero copy/allocation(within the constraints of your language where possible) in deserialize. Which lets you do neat things like mmap it from disk. We used to store 20-30mb of animation data with it and we'd just mmap the whole file and let the kernel handle paging it in/out, worked great. I don't know how up to date their benchmarks[2] are but my experience has been that it beats almost every other off-the-shelf solution(other than maybe capn-proto which has some similar properties). [1] https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/ [2] https://google.github.io/flatbuffers/flatbuffers_benchmarks.html https://google.github.io/flatbuffers/flatbuffers_benchmarks....

jeffbee 4y ago
Those old benchmarks (that have since been deleted) are highly misleading. The protobuf column is essentially what you would get if you just ignored all the performance best practices of protobuf. There's no reason why in C++ you'd need to allocate and deallocate a message struct for every parse. You just reuse it. And you can have allocation-free parses if you want, and you can alias network or file buffers if you want. But the main reason people use protobuf is it is compact, which this table does accurately show. Flatbuffers are always larger.
- vvanders 4y ago
  There is a tradeoff in space / performance, I've just never found for my use cases it was large enough vs the significant(~10x) perf boost I got. From what I recall in the message format[1] protocol buffers require you to walk quite a few parts of the data structures where in flatbuffers you are just reading offset and traversal is significantly faster. Flatbuffers also let's you control data layout into the packed buffer so you can guarantee cache locality which makes a huge difference when it comes to real-world traversal performance. Data oriented design and FlatBuffers go together really well(which isn't a surprise given some of the background of where FlatBuffers comes from). [1] https://developers.google.com/protocol-buffers/docs/encoding#order https://developers.google.com/protocol-buffers/docs/encoding...
  - jeffbee 4y ago
    OK, but I just want readers to be aware that the whole idea that it could take five minutes to parse a million protobufs is completely preposterous. I reimplemented their benchmark just now and it runs at roughly 8 million protos per second, orders of magnitude faster than they state, and I didn't even do anything to optimize it. https://github.com/jwbee/protobuf-flatbuffer-benchmark https://github.com/jwbee/protobuf-flatbuffer-benchmark

jeffbee 4y ago

Those old benchmarks (that have since been deleted) are highly misleading. The protobuf column is essentially what you would get if you just ignored all the performance best practices of protobuf. There's no reason why in C++ you'd need to allocate and deallocate a message struct for every parse. You just reuse it. And you can have allocation-free parses if you want, and you can alias network or file buffers if you want. But the main reason people use protobuf is it is compact, which this table does accurately show. Flatbuffers are always larger.

vvanders 4y ago
There is a tradeoff in space / performance, I've just never found for my use cases it was large enough vs the significant(~10x) perf boost I got. From what I recall in the message format[1] protocol buffers require you to walk quite a few parts of the data structures where in flatbuffers you are just reading offset and traversal is significantly faster. Flatbuffers also let's you control data layout into the packed buffer so you can guarantee cache locality which makes a huge difference when it comes to real-world traversal performance. Data oriented design and FlatBuffers go together really well(which isn't a surprise given some of the background of where FlatBuffers comes from). [1] https://developers.google.com/protocol-buffers/docs/encoding#order https://developers.google.com/protocol-buffers/docs/encoding...
- jeffbee 4y ago
  OK, but I just want readers to be aware that the whole idea that it could take five minutes to parse a million protobufs is completely preposterous. I reimplemented their benchmark just now and it runs at roughly 8 million protos per second, orders of magnitude faster than they state, and I didn't even do anything to optimize it. https://github.com/jwbee/protobuf-flatbuffer-benchmark https://github.com/jwbee/protobuf-flatbuffer-benchmark