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