4 ms·

The article doesn't mention at all how those speedups have been achieved, what tradeoff the format makes and what it is optimized for - which would be the actua

The article doesn't mention at all how those speedups have been achieved, what tradeoff the format makes and what it is optimized for - which would be the actually interesting part. A link to the benchmark code and description of the data would be nice. It also doesn't show data for FlatBuffer, which is often a lot faster and leaner than ProtoBuf, or for Capt'n Proto. ProtoBuf is not exactly known for amazing performance or very optimal client implementations across the various languages. By all means, create a new serialization format, why not. But with so many options to chose from, I would require really strong justification internally.

willtim 6y ago
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/ 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.
- michaelcampbell 6y ago
  And security. SO MANY CVE's related to serialization issues.
schoetbi 6y ago
Totaly agree. I use flatbuffer and it is a lot faster than e.g Json: https://google.github.io/flatbuffers/flatbuffers_benchmarks.html https://google.github.io/flatbuffers/flatbuffers_benchmarks....
tyingq 6y ago
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.
andrewmd5 6y ago
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.
- fyrn- 6y ago
  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.
  - andrewmd5 6y ago
    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.

willtim 6y ago

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

michaelcampbell 6y ago
And security. SO MANY CVE's related to serialization issues.

schoetbi 6y ago

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

tyingq 6y ago

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.

andrewmd5 6y ago

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.

fyrn- 6y ago
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.
- andrewmd5 6y ago
  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.