std.data.json formal review

Dmitry Olshansky via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 11 23:28:27 PDT 2015


On 12-Aug-2015 00:21, Sönke Ludwig wrote:
> Am 11.08.2015 um 20:15 schrieb Dmitry Olshansky:
>> On 11-Aug-2015 20:30, deadalnix wrote:
>>>
>>> Ok some actionable items.
>>>
>>> 1/ How big is a JSON struct ? What is the biggest element in the union ?
>>> Is that element really needed ? Recurse.
>>
>> +1 Also most JS engines use nan-boxing to fit type tag along with the
>> payload in 8 bytes total. At least the _fast_ path of std.data.json
>> should take advantage of similar techniques.
>
> But the array field already needs 16 bytes on 64-bit systems anyway. We
> could surely abuse some bits there to at least not use up more for the
> type tag, but before we go that far, we should first tackle some other
> questions, such as the allocation strategy of JSONValues during parsing,
> the Location field and BigInt/Decimal support.

Pointer to array should work for all fields > 8 bytes. Depending on the 
ratio frequency of value vs frequency of array (which is at least an 
~5-10 in any practical scenario) it would make things both more compact 
and faster.

> Maybe we should first have a vote about whether BigInt/Decimal should be
> supported or not, because that would at least solve some of the
> controversial tradeoffs. I didn't have a use for those personally, but
> at least we had the real-world issue in vibe.d's implementation that a
> ulong wasn't exactly representable.

Well I've stated why I think BigInt should be optional. The reason is 
C++ parsers don't even bother with anything beyond ULong/double, nor 
would any e.g. Node.js stuff bother with things beyond double.

Lastly we don't have BigFloat so supporting BigInt but not BigFloat is 
kinda half-way.

So please make it an option. And again add an extra indirection (that is 
BigInt*) for BigInt field in a union because they are extremely rare.

> My view generally still is that the DOM representation is something for
> convenient manipulation of small chunks of JSON, so that performance is
> not a priority, but feature completeness is.

I'm confused - there must be some struct that represents a useful value. 
And more importantly - is JSONValue going to be converted to jsvar? If 
not - I'm fine. Otherwise whatever inefficiency present in JSONValue 
would be accumulated by this conversion process.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list