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
