Re: [review][JSON] Review of JSON starts today: Sept 14 - Sept 23

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-09-16 15:48:44

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