2 ms·
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 r
by 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 agoOK, 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