On 12/1/24 16:48, Pip Cet wrote:
> Gerd Möllmann<gerd.moellmann@gmail.com> writes:
>
>> Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented
>> at some point, but removed again, see
>>
>>    https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/
>>
>> I vaguely remember a longer thread about GC in json.c at the time. Could
>> be that that was before igc became a realistic possibility, don't
>> remember.
> Okay, sounds like it's a political issue. I'll push the first patch
> which keeps changes to a minimum.
>
> Pip
>

Back then, the future of the new GC was a question, so Gerd said 
(https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00544.html) that
"Please don't take my GC efforts into consideration. That may succeed or 
not. But this is also a matter of good design, using the stack, (which 
BTW pdumper does, too), vs. bad design." That's why we went with the 
fastest implementation that doesn't use lisp vectors for storage. But we 
suspected that this JSON parser design will likely cause a problem with 
the new GC. So I think even if it turned out that the current problem 
was not caused by the parser, I still think that there should be 
something done about this JSON parser design to eliminate this potential 
problem. The lisp vector based approach was reverted because it added an 
extra pressure to the GC. For large JSON messages, it doesn't matter too 
much, but when the JSON is small, the extra GC time made the parser 
measurably slower. But, as far as I remember, that version hadn't have 
the small internal storage optimization yet. If we convert back to the 
vector based approach, the extra GC pressure will be smaller (compared 
to the original vector based approach without the internal storage), as 
for smaller sizes the vector won't be actually used.

Géza