One of the authors of Bebop here:

- The benchmark code is present in the laboratory directory of the repository.

- We don’t compare to Capt’n Proto because it does not have a stable web-based implementation, at least not one that has the features that make it so fast natively, so there is nothing to compare.

- Flatbuffers are fast but have a notoriously awful API to work with while also creating their own non-standard data structures in languages like C++. Bebop generates standard type-safe code.

- Bebop doesn’t try to compress data other than strings. This is because we don’t want to be responsible for compressing trailing zeroes when faster compression algorithms exist that can be down after encoding. Also most data is tiny.

- Bebop supports discriminated unions and has a much more robust type system than Flatbuffers.

- We’re not convincing anyone to use our stuff. It was made for us and open sourced because it was useful; we don’t need people ripping out their current serializers if there’s no pressure to do so.

Even with that I think flatbuffer, is still the main competition for something like this, not including it might make this look more impressive, but including it and mentioning that bebop has some advantages over flatbuffers (although with less language support) would be more fair.

They are impossible to benchmark against each other without making an assumption about how often you want to access the data, and which parts of it you want to access. but this means Bebop and FlatBuffers can exist side-by-side / solve different problems: what FlatBuffers does makes sense if you want to access only parts of your objects in limited specific ways, what we do is better if you're always interested in the whole packet.

Designing a serialisation format has a lot similarities with designing a programming language: data types, declarative/ease-of-use versus full control, abstractions, static versus dynamic memory areas, optimising representations etc. There is definitely room for a variety of formats depending on the use cases; and many are unhappy with the current incumbent: https://reasonablypolymorphic.com/blog/protos-are-wrong/

But yes, it's a lot of work and they probably should document what the trade-offs are that they have made.

And security. SO MANY CVE's related to serialization issues.

It does seem more similar to Capt'n Proto than the things it does compare itself to.

I would guess the high speed is the triad of

    length encoding with a header vs searching for delimiters
    using what they call structs for benchmarks (no repeatedly sending the field name)
    how much you trade off safety/sanity checks for performance

Oh, and keeping ints little endian.

Totaly agree. I use flatbuffer and it is a lot faster than e.g Json: https://google.github.io/flatbuffers/flatbuffers_benchmarks....