bug#31138: Native json slower than json.el

[yyoncho]

Hi Eli,

> OK, but why is that a problem?

It makes native json parsing slower than the elisp parsing and it is unclear why do we get these calls in the performance critical section of the code(at least for lsp-mode) and it is unclear how to avoid them. Without such recipe or a code fix native json parsing will be unusable in combination with any package that attaches yet to be defined extension point. 

Thanks,

Ivan

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

> From: yyoncho <yyoncho@gmail.com>
> Date: Sat, 23 Mar 2019 16:32:48 +0200
> Cc: Sébastien Chapuis <sebastien@chapu.is>,
>       31138@debbugs.gnu.org
>
> 6. At this point, my/call-counter is 32982 which means that json-parse-string has triggered 32982 calls to
> my/test-query-function . I would add also that the number of strings in the json file that I am using is exactly
> 32982 so I suspect that the issue is related to json_make_string .

OK, but why is that a problem?

> Here it is the output of from single invocation of json-parse-string -
> https://gist.github.com/yyoncho/101a87260b407d9f327b24c72ab15a92 - as you can see there are numerous
> elisp functions invoked under json-parse-string.

What I see in the profile is this:

  . json-parse-string takes the lion's share of the CPU time, which is
    expected;
  . some byte-compiled function takes another significant portion of
    CPU time; to see what function is that, load the relevant Lisp
    code from a .el file, instead of from .elc file, then re-run the
    profile

> What I am unable to provide is a minimal example so you could reproduce this behaviour on your side using
> emacs -Q.

Actually, I'm not yet sure what to reproduce.  I'm probably missing
something.