bug#31138: Native json slower than json.el

[Eli Zaretskii]

> From: yyoncho <yyoncho@gmail.com>
> Date: Mon, 25 Mar 2019 21:16:53 +0200
> Cc: Sébastien Chapuis <sebastien@chapu.is>, 
>       31138@debbugs.gnu.org
> 
> I am unable to see any difference in the performance of the json parsing in 
> emacs -q and in my setup - it is
> still ~2 times slower.

You mean, in your setup it's twice slower than in "emacs -Q"?

And you are saying that the changes I made have no effect on the
performance?  Then what about the 100-fold slowdown you were talking
about, allegedly caused by the hooks?

> I believe that it is caused by code_convert_string .

This needs some more specific explanation, because code_convert_string
is called in both your setup and in "emacs -Q".  So it isn't
code_convert_string itself, it's something else, perhaps triggered by
code_convert_string, like those hooks I disabled.

> I compiled emacs without that call and
> there is no difference in performance in both setups and the parsing is 2 
> times faster than emacs -q with
> code_convert_string.

It's small wonder that removing code makes functions which called that
code work faster.  What does removing code_convert_string achieve
except showing this truism in action?

> I want to discuss the native json performance in the context of lsp-mode 
> needs. Is it ok to do it in this thread?

It depends on what you want to discuss, exactly.

And I'm still confused regarding the performance that bothers you.  Is
the problem the two-fold slowdown relative to "emacs -Q", or is the
problem much worse slowdown in some other situation?  Is the patch I
sent useful and should be pushed, or do you no longer care about it
because it doesn't help you?

I feel that I no longer understand what problem we are trying to
solve, and that no matter what improvements I propose, the discussion
always ends up insisting that code_convert_string is the culprit.