rust_serialization_benchmark

CBOR is derived from MessagePack, and is used throughout BlueSky/AtProto. Reports there are that JSON is still the speed champ, by a healthy measure. I am among many who seem to chalk this up to JSON encoding/decoding being fantastically well optimized, having many heavily-invested in very well tuned & optimized libraries available. (Ed: well, https://github.com/djkoloski/rust_serialization_benchmark only shows rust options, but somewhat contradicting this. JSON encoding appears ~3x slower, when looking at best CBOR & JSON performances) This article feels quite broad & high level, as a general introduction. With a couple graphs thrown in at the end to try to close the deal. The space savings I tend to think are probably reasonably representative regardless of the library being tested. But the speed is going to vary greatly, and this is on

rust_serialization_benchmark: https://github.com/djkoloski/rust_serialization_benchmark apache/arrow-rs: https://github.com/apache/arrow-rs From https://arrow.apache.org/faq/ : > How does Arrow relate to Flatbuffers? > Flatbuffers is a low-level building block for binary data serialization. It is not adapted to the representation of large, structured, homogenous data, and does not sit at the right abstraction layer for data analysis tasks. > Arrow is a data layer aimed directly at the needs of data analysis, providing a comprehensive collection of data types required to analytics, built-in support for “null” values (representing missing data), and an expanding toolbox of I/O and computing facilities. > The Arrow file format does use Flatbuffers under the hood to serialize schemas and other metadata needed to implement the Arrow binary I