From: Eli Zaretskii <eliz@gnu.org>
To: yyoncho <yyoncho@gmail.com>
Cc: sebastien@chapu.is, 31138@debbugs.gnu.org
Subject: bug#31138: Native json slower than json.el
Date: Sat, 23 Mar 2019 18:29:54 +0200 [thread overview]
Message-ID: <83d0mhpn99.fsf@gnu.org> (raw)
In-Reply-To: <CACCVLQULs-e-QSZ=8JmG9DFr0OX60ekF=tP1vdpCunjYHY8CtA@mail.gmail.com> (message from yyoncho on Sat, 23 Mar 2019 17:27:58 +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.
next prev parent reply other threads:[~2019-03-23 16:29 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 19:13 bug#31138: Native json slower than json.el Sebastien Chapuis
2018-04-13 7:24 ` Eli Zaretskii
2018-04-15 14:40 ` Sebastien Chapuis
2018-04-15 15:19 ` Eli Zaretskii
2019-03-23 1:59 ` Sébastien Chapuis
2019-03-23 8:15 ` Eli Zaretskii
2019-03-23 9:40 ` Eli Zaretskii
2019-03-23 12:59 ` Sébastien Chapuis
2019-03-23 13:21 ` Eli Zaretskii
2019-03-23 13:31 ` yyoncho
2019-03-23 14:00 ` Eli Zaretskii
2019-03-23 14:32 ` yyoncho
2019-03-23 14:55 ` Eli Zaretskii
2019-03-23 15:27 ` yyoncho
2019-03-23 16:29 ` Eli Zaretskii [this message]
[not found] ` <CACCVLQW=_YngoTwXU+1BDvVVy5jwxSmDFUQJBvs8=PrP=fn=aw@mail.gmail.com>
2019-03-23 18:50 ` Eli Zaretskii
2019-03-23 20:23 ` yyoncho
2019-03-23 20:54 ` Eli Zaretskii
2019-03-23 21:04 ` yyoncho
2019-03-24 3:32 ` Eli Zaretskii
2019-03-24 9:35 ` yyoncho
2019-03-24 11:20 ` Eli Zaretskii
2019-03-24 11:37 ` yyoncho
2019-03-24 15:15 ` Eli Zaretskii
2019-03-24 18:24 ` yyoncho
2019-03-24 18:28 ` Eli Zaretskii
2019-03-24 20:57 ` yyoncho
2019-03-25 3:32 ` Eli Zaretskii
2019-03-25 5:44 ` yyoncho
2019-03-25 16:42 ` Eli Zaretskii
2019-03-25 18:20 ` yyoncho
2019-03-25 18:25 ` Eli Zaretskii
2019-03-25 19:16 ` yyoncho
2019-03-25 20:05 ` Eli Zaretskii
2019-03-25 21:34 ` yyoncho
2019-03-25 23:04 ` Dmitry Gutov
2019-03-26 3:51 ` Eli Zaretskii
2019-03-26 16:14 ` Eli Zaretskii
2019-03-26 17:45 ` yyoncho
2019-03-26 18:11 ` Eli Zaretskii
2019-03-26 18:15 ` yyoncho
2019-04-16 1:36 ` Dmitry Gutov
2019-04-16 2:38 ` Eli Zaretskii
2019-04-16 13:50 ` Dmitry Gutov
2019-04-16 15:13 ` Eli Zaretskii
2019-04-16 15:30 ` Dmitry Gutov
2019-04-16 16:10 ` Eli Zaretskii
2019-04-16 16:23 ` Dmitry Gutov
2019-04-16 16:44 ` Eli Zaretskii
2019-04-21 8:58 ` Eli Zaretskii
2019-04-21 9:15 ` Dmitry Gutov
2019-04-21 9:31 ` Eli Zaretskii
2019-04-21 10:23 ` yyoncho
2019-04-21 10:37 ` Eli Zaretskii
2019-04-21 11:38 ` yyoncho
2019-04-21 12:15 ` Eli Zaretskii
2019-04-21 13:28 ` yyoncho
2019-04-21 19:03 ` Eli Zaretskii
2019-04-21 20:13 ` Eli Zaretskii
2019-04-22 5:38 ` yyoncho
2019-04-22 8:01 ` Eli Zaretskii
2019-04-22 13:00 ` yyoncho
2019-04-22 13:17 ` Eli Zaretskii
2019-04-22 16:53 ` Ivan
2019-04-22 16:58 ` Eli Zaretskii
2019-04-21 22:17 ` Dmitry Gutov
2019-04-22 7:16 ` Eli Zaretskii
2019-04-22 13:54 ` Dmitry Gutov
2019-04-22 15:24 ` Eli Zaretskii
2019-04-22 15:31 ` Dmitry Gutov
2019-04-21 12:59 ` Philipp Stephani
2019-04-21 13:09 ` yyoncho
2019-04-21 13:33 ` Philipp Stephani
2019-04-22 11:48 ` Dmitry Gutov
2019-04-22 12:12 ` Eli Zaretskii
2019-04-22 12:24 ` Dmitry Gutov
2019-04-22 13:02 ` Eli Zaretskii
2019-04-22 15:02 ` Dmitry Gutov
2019-04-22 15:36 ` Eli Zaretskii
2019-04-22 16:16 ` Dmitry Gutov
2019-04-22 16:28 ` Eli Zaretskii
2019-04-22 16:44 ` Dmitry Gutov
2019-04-22 16:50 ` Eli Zaretskii
2019-04-22 17:05 ` Dmitry Gutov
2019-04-22 17:24 ` Eli Zaretskii
2019-04-22 21:03 ` Dmitry Gutov
2019-04-23 10:22 ` Eli Zaretskii
2019-04-23 11:39 ` Dmitry Gutov
2019-04-23 13:19 ` Eli Zaretskii
2019-04-22 16:49 ` Eli Zaretskii
2019-04-22 17:11 ` Dmitry Gutov
2019-04-22 17:26 ` Eli Zaretskii
2019-04-22 22:23 ` Dmitry Gutov
2019-04-23 6:00 ` Eli Zaretskii
2019-04-23 9:46 ` Philipp Stephani
2019-04-23 10:38 ` Eli Zaretskii
2019-04-23 10:44 ` Dmitry Gutov
2019-04-24 2:23 ` Richard Stallman
2019-04-22 17:12 ` Eli Zaretskii
2019-04-22 21:00 ` Dmitry Gutov
2019-04-21 22:14 ` Dmitry Gutov
2019-04-22 7:06 ` Eli Zaretskii
2019-04-21 22:12 ` Dmitry Gutov
2019-04-22 7:03 ` Eli Zaretskii
2019-04-22 11:46 ` Dmitry Gutov
2019-04-22 12:07 ` Eli Zaretskii
2019-04-22 12:58 ` Dmitry Gutov
2019-04-22 13:12 ` Eli Zaretskii
2019-04-22 13:58 ` Dmitry Gutov
2019-04-22 15:25 ` Eli Zaretskii
2019-04-22 15:41 ` Dmitry Gutov
2019-04-22 15:50 ` Eli Zaretskii
2019-04-22 16:00 ` Dmitry Gutov
2019-04-22 16:22 ` Eli Zaretskii
2019-04-22 19:55 ` Dmitry Gutov
2019-04-22 20:28 ` Eli Zaretskii
2019-04-23 11:52 ` Dmitry Gutov
2019-04-23 12:15 ` Eli Zaretskii
2019-04-23 12:37 ` yyoncho
2019-04-23 13:09 ` Eli Zaretskii
2019-04-23 13:27 ` yyoncho
2019-04-23 14:24 ` Eli Zaretskii
2019-04-23 12:37 ` Sébastien Chapuis
2019-04-23 13:10 ` Eli Zaretskii
2019-04-23 14:22 ` Dmitry Gutov
2019-04-23 14:40 ` Philipp Stephani
2019-04-23 15:09 ` Eli Zaretskii
2019-04-23 15:17 ` Eli Zaretskii
2019-04-23 15:36 ` yyoncho
2019-04-23 15:39 ` Eli Zaretskii
2019-04-23 15:43 ` yyoncho
2019-04-23 22:34 ` Dmitry Gutov
2019-04-24 6:20 ` Eli Zaretskii
2019-04-24 6:57 ` Dmitry Gutov
2019-04-24 7:28 ` Eli Zaretskii
2019-04-24 9:52 ` Dmitry Gutov
2019-04-23 14:58 ` Eli Zaretskii
2019-04-24 15:55 ` Dmitry Gutov
2019-04-24 16:21 ` Eli Zaretskii
2019-04-24 16:46 ` Dmitry Gutov
2019-04-24 17:06 ` Eli Zaretskii
2019-04-24 17:36 ` Dmitry Gutov
2019-04-24 17:43 ` Eli Zaretskii
2019-04-24 20:25 ` Dmitry Gutov
2019-04-25 10:44 ` Eli Zaretskii
2019-04-25 14:27 ` Dmitry Gutov
2020-08-22 23:28 ` Lars Ingebrigtsen
2020-08-23 5:50 ` Eli Zaretskii
2019-04-23 14:50 ` Andy Moreton
2019-04-23 15:03 ` Eli Zaretskii
2019-04-23 15:44 ` Andy Moreton
2019-04-22 11:36 ` Dmitry Gutov
2019-04-22 12:01 ` Eli Zaretskii
2019-04-22 13:11 ` Dmitry Gutov
2019-03-30 9:07 ` Eli Zaretskii
2019-04-22 18:20 ` Alex Gramiak
2019-04-22 18:27 ` Eli Zaretskii
2019-04-22 19:52 ` Alex Gramiak
2019-04-22 20:05 ` Dmitry Gutov
2019-04-23 3:06 ` Alex Gramiak
2019-04-23 11:44 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83d0mhpn99.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=31138@debbugs.gnu.org \
--cc=sebastien@chapu.is \
--cc=yyoncho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).