On 16/09/2020 16:05, Peter Dimov via Boost wrote:
Niall Douglas wrote:
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.
That's not a fair comparison, because you need fewer Gb to encode the same thing in CBOR.
This is true, but I didn't mention that I was accounting already for that. CBOR had about 15% overhead from binary when I last tested it. JSON for the data we were transmitting it was around 50%. However simdjson and sajson are many many times faster than the CBOR library I tested, and JSON compresses very easily. I guess what I'm really saying here is that yes, JSON emits less dense data than CBOR. But, a recent JSON parser + snappy compression produces denser representation than CBOR, and yet is still faster overall. I'm very sure that a faster CBOR library is possible than what we have. But given what's currently available in the ecosystem, I'm saying a recent JSON library + fast compression is both faster and smaller output than currently available alternatives right now. This is why I'm not keen on CBOR personally. I don't think it solves a problem anyone actually currently has, rather it solves a problem people think they have because they haven't considered adding a compression pass to a fast JSON implementation. Niall