bug#31138: Native json slower than json.el

[yyoncho]

Hi Eli,

Take a look at the following piece of code:

https://gist.github.com/yyoncho/9e9c4e14734fdd9a22d6600a88a27ae1

(with the latest emacs compiled from master)

Unfortunately, I wasn't unable to reproduce the behaviour with "emacs -q" and even it does not reproduce right after I load my emacs configuration but after doing some navigation/coding. I believe that native parsing is calling some function list defined in the elisp space but I am unable to track down this. Please, let me know what I can do to help to diagnose this issue.

Thanks,

Ivan

On Sat, Mar 23, 2019 at 3:21 PM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Sébastien Chapuis <sebastien@chapu.is>
> Date: Sat, 23 Mar 2019 20:59:46 +0800
> Cc: Ivan Yonchovski <yyoncho@gmail.com>, 31138@debbugs.gnu.org
>
> Sorry for not being clear, my main concern was the difference when
> wrapping json-parse-string with with-temp-buffer or not.

Ah, okay.  I thought the concern was with the native JSON support
being slower than json.el.

> You are right, I tested with the current master branch and it is
> faster (emacs -Q):
>
> (with-current-buffer  "large.json"
>   (benchmark-run 10 (json-parse-string (buffer-string))))
> ;;; (1.45898128 10 0.15294547200000003)
>
> (with-current-buffer  "large.json"
>   (let ((str (buffer-string)))
>     (benchmark-run 10 (with-temp-buffer (json-parse-string str)))))
> ;;; (0.706171416 10 0.18795709700000002)
>
> (with-current-buffer  "large.json"
>   (let ((str (buffer-string)))
>     (benchmark-run 10 (with-temp-buffer (json-read-from-string str)))))
> ;;; (2.476727624 138 1.5660531400000006)

OK, this is consistent with what I see: about 3- to 4-fold speedup
from using the native JSON support.

> I have tested to read the file literally, as you suggested and there
> is now no difference with or without with-temp-buffer (emacs -Q):
>
> (with-current-buffer (find-file-noselect "large.json" nil t)
>   (benchmark-run 10 (json-parse-string (buffer-string))))
> ;;; (0.7011264119999999 10 0.118889765)
>
> (with-current-buffer  (find-file-noselect "large.json" nil t)
>   (let ((str (buffer-string)))
>     (benchmark-run 10 (with-temp-buffer (json-parse-string str)))))
> ;;; (0.7159130309999999 10 0.15112133999999997)

I didn't mean find-file-noselect, I meant find-file-literally.  Which
one did you use in your testing?

> For the context, with lsp-mode, we have users complaining about
> performance of json-parse-string [1].
> Some have found out that the function is way faster with emacs -Q but
> it is "dead slow" with their Spacemacs setup.
>
> In lsp-mode, we are reading child process output by calling
> `make-process` with `:coding 'no-conversion`, I think it has the same
> behavior than reading a file "literally" ?

Yes.

> Is there anything else we could do to improve the performance from
> reading the process output ?

I don't know yet, let's first try to solve the issue below:

> Now the problem is how can we have the same performance with a regular
> emacs setup than with emacs -Q ?
> With my emacs setup, I have this result:
>
> (with-current-buffer (find-file-noselect "large.json" nil t)
>   (benchmark-run 10 (json-parse-string (buffer-string))))
> ;;; (1.515018996 10 0.5256668049999996)
>
> (with-current-buffer (find-file-noselect "large.json" nil t)
>   (let ((str (buffer-string)))
>     (benchmark-run 10 (with-temp-buffer (json-parse-string str)))))
> ;;; (1.156755376 10 0.5596599300000001)
>
> This is almost 2x slower than with emacs -Q.
> Note that there is still a difference with and without `with-temp-buffer`.
> What can we do to reach emacs -Q performance ?

I think the only sure way is to find the customization(s) which are
responsible for the slowdown.  First, use find-file-literally, and if
that doesn't help, bisect your customizations to find which one(s)
cause this two-fold slowdown.

Once you identify the customizations responsible for the slowdown, we
could then try to figure out whether that is due to some bugs or not,
and if the latter, then how to avoid the slowdown even with those
customizations in effect.

Thanks.