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

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-09-16 14:49:26

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