bug#31138: Native json slower than json.el

[yyoncho <yyoncho@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3724 bytes --]

Hi Eli,

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

Yes.


> 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?
>

The slowdown caused by the hooks was caused by the C-g and the issue does
not exist and it is fixed by your patch. Otherwise, it is ~0.6 vs ~1.2secs.


> > 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.
>

Yes, I think that it is related to switching to different buffers.


>
> > 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?
>

It is actually very helpful for me and I guess for you:

1. Now we know where to look for if we want to optimize further emacs -q
parsing performance.
2. Now we know what the difference between emacs -q performance and my
setup is caused by something in that function.


>
> > 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?
>

IMO the fix should go in, I summarized what are lsp-mode problems.


> 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.
>

...and it actually *was* the culprit, right?  Furthermore, it the
performance test that I mentioned proves it is *still* the culprit...

Here it is the summary of the issues that I see in native json parsing from
lsp-mode (beware that I will list issues that are not relevant to that bug
bug#31138).

1. Hooks might be triggered when performing json parsing(fixed by you). I
hoped that this will fix 2) but apparently these are two separate issues.
2. There is a difference in performance between emacs -q and non-"emacs -q"
. I would expect json parsing to be side effect free. (My guess is that it
is related to switching buffers because with-temp-buffer has some positive
effect).
3. Even in the best case scenario native parsing is not fast enough. In
lsp-mode, you might receive 3.5mb json as a server-side response while you
are typing. E. g. I might type "abc" and get 10.5 mb json. I compared the
performance of nodejs parsing and it is ~10 times faster than emacs -q.
4. JSON parsing can be performed only on the UI thread.

Alternatively, we (lsp-mode team) will be able to solve all these in a
dynamic module if emacs module mechanism is extended to allow creating
emacs lisp structures efficiently.

PS: I really enjoy the ironical passive-aggressive style of communication
which I guess is common for emacs-devel but I will still be trying to be
constructive. I just want you to know that I won't bother answering and
focus only on the stuff that will help to solve the issue...

Thanks,
Ivan

[-- Attachment #2: Type: text/html, Size: 5209 bytes --]