Re: [PATCH] Implement fast verisons of json-parse functions

["Herman, Géza" <geza.herman@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks.  I installed this on the master branch, after adding the
> required commit log messages and some cleanup of unused 
> functions.
Thanks!

> However:
>
>   . 3 tests in test/src/json-tests.el are now failing, where 
>   they
>     succeeded before; see the log at the end
>   . the times of the relevant tests don't seem to be faster than
>     the libjansson version, perhaps because this is an 
>     unoptimized
>     build

3 test failures:
1. Handling of utf-8 decode errors: the new parser emits 
json-utf8-decode-error instead of json-parse-error (this is what 
the test expects).  I can fix this by modifying the test
2. Handling of a single \0 byte: the new parser emits 
json-end-of-file.  I think this is not the best error kind for 
this case, so I'll modify the parser to emit json-parse-error 
instead.  This is still different what the test expects 
(wrong-type-argument), but I think there is no reason to treat 
zero bytes specially.  Considering the JSON spec, it's the same 
error as any other unexpected byte value.
3. Handling objects with duplicate keys.  That's an interesting 
one.  With alist/plist objects, the old parser removed duplicate 
members, but the new parser doesn't remove such members, it keeps 
them all. The JSON spec doesn't really say anything about this 
case, so I think we're free to do anything we like. Mattias 
Engdegård had an interesting idea: what if we put alist/plist 
members in reversed order? This way, if one uses assq/plist-get to 
get values by keys, the behavior will be consistent with the hash 
table representation (which keeps that last value of duplicate 
keys).  I like the idea of consistency, but I don't like that the 
elements will become reversed after parsing.  I had the idea that 
if the hash table kept the first value of duplicate keys, then 
we'd also have consistency.  What do you think?

Regarding performance: the new parser only becames significantly 
faster on larger JSONs only.  And yes, unoptimized build also has 
an impact on performance.