bug#31138: Native json slower than json.el

[Eli Zaretskii]

> From: yyoncho <yyoncho@gmail.com>
> Date: Mon, 25 Mar 2019 23:34:38 +0200
> Cc: Sébastien Chapuis <sebastien@chapu.is>, 
>       31138@debbugs.gnu.org
> 
>  You mean, in your setup it's twice slower than in "emacs -Q"?
>  
> Yes.

Then my suggestion to bisect your setup still stands.  Alternatively,
if you can find a recipe where this happens and post it, I will look
into it.

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

For 10 benchmark runs?

And even if it's twice slower than "emacs -Q", it should be still
almost twice faster than the Lisp implementation, at least that's what
I see on 2 different machines with 2 different OSes.

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

Then json-parse-buffer doesn't have this problem in your setup?

> 1. Now we know where to look for if we want to optimize further emacs -q 
> parsing performance.

I'm not sure we know that.  We didn't analyze the profile below the
Lisp primitives level.  If we want to see what takes significant parts
of the time in the benchmark runs, we need to use perf and look at the
C level below the primitives

> 2. Now we know what the difference between emacs -q performance and my setup 
> is caused by something in
> that function.

No, I don't think we know that.  You say above that it's caused by
switching buffers, which is not in code_convert_string.

> IMO the fix should go in

OK, will do.

> I summarized what are lsp-mode problems. 

What are they?  Can you summarize them again, please, or point me to
where you did so?

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

No, the culprit was the hooks we called as a side effect of that function.

> Furthermore, it the performance test that I mentioned proves it is
> *still* the culprit...

I'm sorry, but I don't see that proof.  Can you explain how you arrive
at that conclusion?

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

Agreed.  So the issue with hooks no longer exists (once the patch I
sent is committed).

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

I don't think I understand this.  What side effects are you talking
about?  Switching buffers is not part of json-parse-string.

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

10 times faster doesn't mean Emacs isn't "fast enough".  The current
native parsing is faster than what we had before in Lisp, so this is
progress.

And if we want to see how to optimize JSON parsing in Emacs even more,
we need to profile the code with a large enough JSON, and see what
takes the time.

> 4. JSON parsing can be performed only on the UI thread. 

You can do that in a separate thread in a module.

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

What is lacking in the modules mechanism?

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

I actually think that discussions on emacs-devel, with a few
exceptions, are generally to the point and quite productive.