Simdjson – Parsing Gigabytes of JSON per Second

201–202 of 202 posts

Re: Simdjson – Parsing Gigabytes of JSON per Second

#201

Post by kragen » Mon, Feb 25, 2019, 5:56 AM UTC

spc476 wrote: post #177

kragen wrote: post #171

Earlier quoted context omitted.

After spending most of a year doing deep surgery on systems that used CBOR extensively, I can report that the common CBOR parsers are not faster than common JSON parsers; surprisingly, they are actually slower. CBOR is also not easier; it's much less widely supported, and you need a separate debugging representation. It does have three real advantages over JSON: it supports binary strings, it's a monument to Carsten…

There are a few more advantages to CBOR: 1) there's a distinction between integers and floating point values; 2) you can semantically tag values (yes, this is a text string, but treat it as a date; this is a binary string, but treat it as a big number; etc.); 3) you can have maps with non-text keys. I'm not sure what Carsten Bormann's ego has to do with CBOR, but I found RFC-7049 one of the better written specs, with…

All three of those could be advantages under some circumstances, but I've more often found them to be disadvantages. What do you do with maps with non-text keys when you're deserializing in JS or Perl? For that matter, what do you do in Python when the key of a map is a map? When you have a date, do you decode it as a datetime object, as a text string, or as some kind of wrapper object that gives you both alternatives?

I agree that having lots of examples in the spec is good.

Re: Simdjson – Parsing Gigabytes of JSON per Second

#202

Post by spc476 » Tue, Feb 26, 2019, 7:35 PM UTC

kragen wrote: post #201

spc476 wrote: post #177

Earlier quoted context omitted.

There are a few more advantages to CBOR: 1) there's a distinction between integers and floating point values; 2) you can semantically tag values (yes, this is a text string, but treat it as a date; this is a binary string, but treat it as a big number; etc.); 3) you can have maps with non-text keys. I'm not sure what Carsten Bormann's ego has to do with CBOR, but I found RFC-7049 one of the better written specs, with…

All three of those could be advantages under some circumstances, but I've more often found them to be disadvantages. What do you do with maps with non-text keys when you're deserializing in JS or Perl? For that matter, what do you do in Python when the key of a map is a map? When you have a date, do you decode it as a datetime object, as a text string, or as some kind of wrapper object that gives you both alternative…

> What do you do with maps with non-text keys when you're deserializing in JS or Perl?

Um, use another language? I use Lua, which can deal with non-text keys. As for decoding dates (if they're semantically tagged, which you can with CBOR) I convert it to a datetime object, on the grounds that if I care about tagged dates, I'm going to be using them in some capacity.

But that's not to say you have to use the flexibility of CBOR. But for me, having distinct integer and floating point values, plus distinct text and binary data, is enough of a win to use it over JSON.

Post reply on HN