41–50 of 60 posts
Earlier quoted context omitted.
There's also FlatBuffer, which is also specifically made for Gaming application by Google.
Originally created by Wouter van Oortmerssen http://strlen.com/
There's gotta now be way too many serialisation formats. Each one claiming similar things to others. What would be helpful is a concrete example showing what was tried with an existing approach that fell short. I mean code, benchmarks, theory.
We need an independent reviewer of serialization formats!
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 perform…
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/ Bu…
I only opened this article to see a comparison with FlatBuffers and got disappointed. :( To be fair though, I am open to the idea of having a separate schema definition language, at least. (And please don't say DDL, it doesn't even come close.)
FlatBuffers creates its own demented and completely incompatible data structures when deserializing into C++. Which means you then need to copy the FlatBuffers structures into normal ones, defeating the entire point of "zero-copy" in the first place. This thing it looks like uses normal C++ structures under the hood, and if so that's a huge plus.
So there are stucts (all values present), messages (some values may be omitted) and enums (pick one, but has not value). I miss "tagged unions" or enums with values a.k.a. sumtypes.
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 perform…
- 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.
Earlier quoted context omitted.
Speaking of which, I’ve never seen a marshaling protocol with as sophisticated a message versioning scheme as ASN.1. The amount of thought that went into specifying how to allow “implementations from the future” to interoperate with those of the past is impressive.
And yet outclassed on any meaningful metric by generic serialization languages? ASN.1 is a programming language in addition to a data transport format opening up many opportunities for security vulnerabilities. Performance is shit because it’s using text to encode everything so that it’s human readable. Similarly parsing is extra complicated and slow for that reason. Serialization/deserialization requires a dedicated…
A weird criticism considering the encoding rules usually used for ASN.1 are all binary and some of them are bit-packed (like PER), which is very uncommon in newer protocols (for good reason).
Oh and there is OER now, which is actually a very reasonable binary encoding.
This year's ASN.1 BER. Again