bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31138: Native json slower than json.el


From: Eli Zaretskii
Subject: bug#31138: Native json slower than json.el
Date: Sat, 23 Mar 2019 18:29:54 +0200

> From: yyoncho <yyoncho@gmail.com>
> Date: Sat, 23 Mar 2019 17:27:58 +0200
> Cc: Sébastien Chapuis <sebastien@chapu.is>, 
>       31138@debbugs.gnu.org
> 
> > 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. 

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?

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
don't think we have established that yet; the large number of calls to
that function doesn't by itself mean it consumes a significant portion
of CPU time.

And I'm now confused what is the issue we are investigating here.
Originally, it seemed like the problem was the native JSON processing
being slower than the Lisp implementation.  Then we've established
that the native implementation is 3 to 4 times faster, and the problem
was that in "emacs -Q" it is twice faster than in OP's customized
Emacs session; I suggested a way to try to find the reason(s) for that
slowdown.  Now it seems like you are saying that json_make_string
could be the problem, and the rest of the issue is not really
interesting?  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.

And I still think you should run the profile with *.el files, to see
what is that compiled function which took a significant percentage of
processing time in the profile you showed.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]