On 16/09/2020 14:53, Peter Dimov via Boost wrote:
Niall Douglas wrote:
In any case, CBOR is actually a fairly lousy binary protocol. Very inefficient compared to alternatives.
I actually quite like CBOR. Of all the "binary JSON" protocols, it's the best. Or the least worst, if you will. (Except for MessagePack, which I like even more, but it's arguably not a binary JSON.)
I know what you're saying. However, comparing **C++ implementations** of CBOR to JSON ones does not yield much differential. For example, simdjson will happily sustain 10 Gbit of textual JSON parsing per session which is enough for most NICs. CBOR parsers, at least the ones available to C++, are no better than this. Our custom DB will push 20-25Gb/sec, so we'd need a 250 Gbit NIC and a zero copy all binary network protocol to have the DB become the primary bottleneck. I doubt any CBOR like design could achieve that, ever, because that design is fundamentally anti-performance. CBOR's primary gain for me is exact bit for bit value transfer, so floating point numbers come out exactly as you sent them. That's rarely needed outside scientific niches though, and even then, just send the FP number as a string encoded in hexadecimal in JSON right? In fact, for any format which looks better than JSON, encoding your values as hexadecimal strings in JSON is an excellent workaround. Hexadecimal string parsing is very, very fast on modern CPUs, you often can add +20% to JSON bottlenecked performance by using hexadecimal for everything. Niall