bug#31138: Native json slower than json.el

[Eli Zaretskii]

> From: yyoncho <yyoncho@gmail.com>
> Date: Sat, 23 Mar 2019 20:03:29 +0200
> 
>  Sorry, I don't think I understand the issue.  Currently, the native
>  JSON parsing is between 3 and 4 times faster than the Lisp
>  implementation, as shown by my benchmarks posted here, which were
>  confirmed by Sébastien.  So it cannot be unusable, not more so than
>  the Lisp implementation.  Am I missing something?
> 
> You asked why native json parsing calling "kill-buffer-query-functions" for 
> each string transformation is a
> problem - my answer to that is that if we do not find a way to fix that 
> native json parsing will not be usable for
> Elisp developer since it will get slower depending on external factors.
> 
>  As for avoiding the calls to json_make_string: before we discuss that,
>  we should at least establish that those calls eat up a significant
>  percentage of the CPU time in the use cases that are of interest.
> 
> I do not want to avoid calls to json_make_string but I want json_make_string 
> to be changed so it does not
> trigger "kill-buffer-query-functions".

Ah, okay.  Thanks for explaining the problem to me, I now understand
what's bothering you.

However, I cannot reproduce what you describe, not with the latest
Emacs master branch.  When I repeat the recipe you posted in

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

I get zero as the final value of the counter, not 32982.  As I'd
expect, as I don't see why kill-buffer-query-functions would be called
in this scenario.  This was in "emacs -Q", do you get a non-zero count
even in "emacs -Q"?

To see why kill-buffer-query-functions is invoked in your case, I
suggest the following:

  . Modify the above recipe to call 'message' inside
    my/test-query-function.
  . Run Emacs under GDB after putting a breakpoint in Fmessage (this
    is the C name of 'message').
  . Run your recipe.  When the breakpoint in 'message' breaks, display
    the Lisp backtrace using the "xbacktrace" command (it is defined
    in src/.gdbinit in the Emacs source tree).

Alternatively (and maybe easier for you), set debug-on-entry to
trigger when my/test-query-function is called, then run your recipe,
and look at the backtrace to see why it was called.

I hope that either of these two ways will allow you to find the code
which is responsible for calling kill-buffer-query-functions when JSON
string is being parsed.  Once we understand that, we could see how to
avoid it.

>  If so, my suggestion would be to run Emacs under 'perf'
>  and see which parts of json-parse-string take most of the CPU time,
>  then we'd have solid basis for discussing the significance of the
>  calls to json_make_string in this scenario.  If you want me to do the
>  'perf' run (with the caveat that in "emacs -Q" it might run faster
>  than in your customized Emacs), please give a complete recipe, and I
>  will do it.
> 
> Like I said in the first mail - I cannot give you the recipe since I am not 
> able to track down what is causing that
> slowdown and I need help on that. Can you give me a link on how to run emacs 
> under "perf"?

Here are a few:

  http://www.brendangregg.com/perf.html
  https://perf.wiki.kernel.org/index.php/Tutorial#Sampling_with_perf_record
  
https://perf.wiki.kernel.org/index.php/Tutorial#Sample_analysis_with_perf_report

The perf man pages are also useful.