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