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.