Re: I created a faster JSON parser

[Mattias Engdegård]

11 mars 2024 kl. 15.35 skrev Herman, Géza <geza.herman@gmail.com>:

> According to https://github.com/miloyip/nativejson-benchmark, RapidJSON is at 
> least 10x faster than jansson.  I'm just saying this because Emacs doesn't 
> have to stick with my parser, there are possible alternatives, which have 
> JSON serializers as well.

Thanks for the benchmark page reference. Yes, if this turns out to matter more 
we may consider a faster library. Right now I think your efforts are good 
enough (at least if we finish the job with a JSON serialiser).

> Yep, the formatting of that table got destroyed when I reformatted the code 
> into GNU style.  Now I formatted the table back, and added comments for each 
> row/col.  Here's the latest version: 
> https://github.com/geza-herman/emacs/commit/4b5895636c1ec06e630baf47881b246c198af056.patch

Much better, thank you.

>> * Do you really need to maintain line and column during the parse? If
>> you want them for error reporting, you can materialise them from the
>> offset that you already have.
> 
> Yeah, I thought of that, but it turned out that maintaining the line/column 
> doesn't have an impact on performance.

That's just because your code isn't fast enough! We are very disappointed. Very.

>  I added that easily, tough admittedly it's a little bit awkward to maintain 
> these variables.  If emacs has a way to tell from the byte-pointer the 
> line/col position (both for strings and buffers), I am happy to use that 
> instead.

Since error handling isn't performance-critical it doesn't matter if it's a bit 
slow. (I'd just count newlines.)

>> * Are you sure that GC can't run during parsing or that all your Lisp
>> objects are reachable directly from the stack? (It's the
>> `object_workspace` in particular that's worrying me a bit.)
> 
> That's a very good question.  I suppose that object_workspace is invisible to 
> the Lisp VM, as it is just a malloc'd object.  But I've never seen a problem 
> because of this.  What triggers the GC? Is it possible that for the duration 
> of the whole parsing, GC is never get triggered?  Otherwise it should have 
> GCd the objects in object_workspace, causing problems (I tried this parser in 
> a loop, where GC is caused hundreds of times. In the loop, I compared the 
> result to json-read, everything was fine).

You can't test that code is GC-safe, you have to show that it's correct by 
design.

Looking at the code it is quite possible that GC cannot take place. But it can 
signal errors, and getting into the debugger should open GC windows unless I'm 
mistaken.

There are some options. `record_unwind_protect_ptr_mark` would be one, and it 
was made for code like this, but Gerd has been grumbling about it lately. 
Perhaps it's easier just to disable GC in the dynamic scope 
(inhibit_garbage_collection).