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