From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: yyoncho Newsgroups: gmane.emacs.bugs Subject: bug#31138: Native json slower than json.el Date: Sat, 23 Mar 2019 15:31:39 +0200 Message-ID: References: <87sh806xwa.fsf@chapu.is> <834lkf7ely.fsf@gnu.org> <878t9own1p.fsf@chapu.is> <838t9o4hvl.fsf@gnu.org> <83r2ayovkx.fsf@gnu.org> <83pnqiormy.fsf@gnu.org> <83lg15pvzr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007359f70584c2fed6" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186502"; mail-complaints-to="usenet@blaine.gmane.org" Cc: =?UTF-8?Q?S=C3=A9bastien?= Chapuis , 31138@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 23 17:05:43 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h7j9S-000mOQ-N8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 17:05:42 +0100 Original-Received: from localhost ([127.0.0.1]:45205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7j9R-000535-OI for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 12:05:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7j7B-0003Q6-U1 for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 12:03:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7iz8-0004Fb-1n for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 11:55:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42166) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h7iz7-0004Es-To for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 11:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h7iz7-00078y-Rk for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 11:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: yyoncho Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Mar 2019 15:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31138 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 31138-submit@debbugs.gnu.org id=B31138.155335645327381 (code B ref 31138); Sat, 23 Mar 2019 15:55:01 +0000 Original-Received: (at 31138) by debbugs.gnu.org; 23 Mar 2019 15:54:13 +0000 Original-Received: from localhost ([127.0.0.1]:55706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7iyK-00077Y-C9 for submit@debbugs.gnu.org; Sat, 23 Mar 2019 11:54:13 -0400 Original-Received: from mail-qt1-f170.google.com ([209.85.160.170]:46987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7gke-0003Xn-Nv for 31138@debbugs.gnu.org; Sat, 23 Mar 2019 09:31:57 -0400 Original-Received: by mail-qt1-f170.google.com with SMTP id z17so5570292qts.13 for <31138@debbugs.gnu.org>; Sat, 23 Mar 2019 06:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5tddGI6aDz5PwB3rfuHTxN07G/X02xchEZi1TaEH1bI=; b=Qh3WGWcyjnj8b2tCFQ5VxMVXa4rnNcv1C2LP6YXtmdmbIaDR8u8NE4J0kHHmkBbJ5H OSgZRS1BLAMLjfCQ8xp+JLu3UOoxXe6gDoFIAvO0kkgLqK2KMdX5wtzvNFu/If+YAV/U G/6F+KNdtKUNsHXywC/8Fncf/z/fW0ISvhUkMkMyROkNYMJz2okGrhBEVNTR1Tp76m1M 9/mb+E4dmTKTGKzR2ePYVEmabKktpeEAbiC/C5ubmGDIHo7CbuqG968hvmYsPe2GaF4q gjJucSaqhwV/y67shk4QgHTjt/DopvAczWQSe7yOzQZCKzcLYsIClWMe1UHL4tDeYoWw tPeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5tddGI6aDz5PwB3rfuHTxN07G/X02xchEZi1TaEH1bI=; b=ZgMxto5qsbTOT6/lOqwQAOQKoJkCotlINEehujEg0zTxdVIwNaIEoz5JUOIzCWKxL5 laCX0C/1cxJjXAAj0ZgwAv+JB5crpvLrZlBrIeyBEwKM9IeOol0xGmL25R7z7V+hshc0 U2jNk6s7dlX5CdV4NFNuzyKFwY48NxrTr8D5Mv7dYGyab+A04Mo/YUgh6s9A01Gs+2yt IPttuQpEZr8H0MMfty2ZQMqtEjq2KkD0n8bI0TifIqZioirZzppgCFhhV4NVeqpB+6+Q h6jFHlrzkdW7TrdzWcnVLAJKkJONb65GlWg1utBUGT2RIootOY/WD8GTBD7SUbHF8TAF O5jA== X-Gm-Message-State: APjAAAUeZBa0qSqAu5IKZlZIF3xOFoD1lCZp2sEseNslTY+xRa1kqgdN zqesMN/sNPJUsbbiKBsOR4TSmJMN/m2JoyAc8Cg= X-Google-Smtp-Source: APXvYqyVginLZZR6qSS6q4V1cjzP91BPO1YBK+R7o8HuOBWLn65d0RR6Wewn9VlAaYeqFNtfA7ON7oyhjvWOwtErFMk= X-Received: by 2002:a0c:d1a6:: with SMTP id e35mr12713177qvh.174.1553347911046; Sat, 23 Mar 2019 06:31:51 -0700 (PDT) In-Reply-To: <83lg15pvzr.fsf@gnu.org> X-Mailman-Approved-At: Sat, 23 Mar 2019 11:54:11 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:156672 Archived-At: --0000000000007359f70584c2fed6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eli, Take a look at the following piece of code: https://gist.github.com/yyoncho/9e9c4e14734fdd9a22d6600a88a27ae1 (with the latest emacs compiled from master) Unfortunately, I wasn't unable to reproduce the behaviour with "emacs -q" and even it does not reproduce right after I load my emacs configuration but after doing some navigation/coding. I believe that native parsing is calling some function list defined in the elisp space but I am unable to track down this. Please, let me know what I can do to help to diagnose this issue. Thanks, Ivan On Sat, Mar 23, 2019 at 3:21 PM Eli Zaretskii wrote: > > From: S=C3=A9bastien Chapuis > > Date: Sat, 23 Mar 2019 20:59:46 +0800 > > Cc: Ivan Yonchovski , 31138@debbugs.gnu.org > > > > Sorry for not being clear, my main concern was the difference when > > wrapping json-parse-string with with-temp-buffer or not. > > Ah, okay. I thought the concern was with the native JSON support > being slower than json.el. > > > You are right, I tested with the current master branch and it is > > faster (emacs -Q): > > > > (with-current-buffer "large.json" > > (benchmark-run 10 (json-parse-string (buffer-string)))) > > ;;; (1.45898128 10 0.15294547200000003) > > > > (with-current-buffer "large.json" > > (let ((str (buffer-string))) > > (benchmark-run 10 (with-temp-buffer (json-parse-string str))))) > > ;;; (0.706171416 10 0.18795709700000002) > > > > (with-current-buffer "large.json" > > (let ((str (buffer-string))) > > (benchmark-run 10 (with-temp-buffer (json-read-from-string str))))) > > ;;; (2.476727624 138 1.5660531400000006) > > OK, this is consistent with what I see: about 3- to 4-fold speedup > from using the native JSON support. > > > I have tested to read the file literally, as you suggested and there > > is now no difference with or without with-temp-buffer (emacs -Q): > > > > (with-current-buffer (find-file-noselect "large.json" nil t) > > (benchmark-run 10 (json-parse-string (buffer-string)))) > > ;;; (0.7011264119999999 10 0.118889765) > > > > (with-current-buffer (find-file-noselect "large.json" nil t) > > (let ((str (buffer-string))) > > (benchmark-run 10 (with-temp-buffer (json-parse-string str))))) > > ;;; (0.7159130309999999 10 0.15112133999999997) > > I didn't mean find-file-noselect, I meant find-file-literally. Which > one did you use in your testing? > > > For the context, with lsp-mode, we have users complaining about > > performance of json-parse-string [1]. > > Some have found out that the function is way faster with emacs -Q but > > it is "dead slow" with their Spacemacs setup. > > > > In lsp-mode, we are reading child process output by calling > > `make-process` with `:coding 'no-conversion`, I think it has the same > > behavior than reading a file "literally" ? > > Yes. > > > Is there anything else we could do to improve the performance from > > reading the process output ? > > I don't know yet, let's first try to solve the issue below: > > > Now the problem is how can we have the same performance with a regular > > emacs setup than with emacs -Q ? > > With my emacs setup, I have this result: > > > > (with-current-buffer (find-file-noselect "large.json" nil t) > > (benchmark-run 10 (json-parse-string (buffer-string)))) > > ;;; (1.515018996 10 0.5256668049999996) > > > > (with-current-buffer (find-file-noselect "large.json" nil t) > > (let ((str (buffer-string))) > > (benchmark-run 10 (with-temp-buffer (json-parse-string str))))) > > ;;; (1.156755376 10 0.5596599300000001) > > > > This is almost 2x slower than with emacs -Q. > > Note that there is still a difference with and without > `with-temp-buffer`. > > What can we do to reach emacs -Q performance ? > > I think the only sure way is to find the customization(s) which are > responsible for the slowdown. First, use find-file-literally, and if > that doesn't help, bisect your customizations to find which one(s) > cause this two-fold slowdown. > > Once you identify the customizations responsible for the slowdown, we > could then try to figure out whether that is due to some bugs or not, > and if the latter, then how to avoid the slowdown even with those > customizations in effect. > > Thanks. > --0000000000007359f70584c2fed6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli,

Take a look at= the following piece of code:

(with the = latest emacs compiled from master)

Unfortunate= ly, I wasn't unable to reproduce the behaviour=C2=A0with "emacs -q= " and even it does not reproduce right after I load my emacs configura= tion but after doing some navigation/coding. I believe that native parsing = is calling some function list defined in the elisp=C2=A0space but I am unab= le to track down this. Please, let me know what I can do to help to diagnos= e this issue.

Thanks,
Ivan

On Sat, Mar 23, 2019 at 3:21 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: S=C3=A9bastien Chapuis <sebastien@chapu.is>
> Date: Sat, 23 Mar 2019 20:59:46 +0800
> Cc: Ivan Yonchovski <yyoncho@gmail.com>, 31138@debbugs.gnu.org
>
> Sorry for not being clear, my main concern was the difference when
> wrapping json-parse-string with with-temp-buffer or not.

Ah, okay.=C2=A0 I thought the concern was with the native JSON support
being slower than json.el.

> You are right, I tested with the current master branch and it is
> faster (emacs -Q):
>
> (with-current-buffer=C2=A0 "large.json"
>=C2=A0 =C2=A0(benchmark-run 10 (json-parse-string (buffer-string)))) > ;;; (1.45898128 10 0.15294547200000003)
>
> (with-current-buffer=C2=A0 "large.json"
>=C2=A0 =C2=A0(let ((str (buffer-string)))
>=C2=A0 =C2=A0 =C2=A0(benchmark-run 10 (with-temp-buffer (json-parse-str= ing str)))))
> ;;; (0.706171416 10 0.18795709700000002)
>
> (with-current-buffer=C2=A0 "large.json"
>=C2=A0 =C2=A0(let ((str (buffer-string)))
>=C2=A0 =C2=A0 =C2=A0(benchmark-run 10 (with-temp-buffer (json-read-from= -string str)))))
> ;;; (2.476727624 138 1.5660531400000006)

OK, this is consistent with what I see: about 3- to 4-fold speedup
from using the native JSON support.

> I have tested to read the file literally, as you suggested and there > is now no difference with or without with-temp-buffer (emacs -Q):
>
> (with-current-buffer (find-file-noselect "large.json" nil t)=
>=C2=A0 =C2=A0(benchmark-run 10 (json-parse-string (buffer-string)))) > ;;; (0.7011264119999999 10 0.118889765)
>
> (with-current-buffer=C2=A0 (find-file-noselect "large.json" = nil t)
>=C2=A0 =C2=A0(let ((str (buffer-string)))
>=C2=A0 =C2=A0 =C2=A0(benchmark-run 10 (with-temp-buffer (json-parse-str= ing str)))))
> ;;; (0.7159130309999999 10 0.15112133999999997)

I didn't mean find-file-noselect, I meant find-file-literally.=C2=A0 Wh= ich
one did you use in your testing?

> For the context, with lsp-mode, we have users complaining about
> performance of json-parse-string [1].
> Some have found out that the function is way faster with emacs -Q but<= br> > it is "dead slow" with their Spacemacs setup.
>
> In lsp-mode, we are reading child process output by calling
> `make-process` with `:coding 'no-conversion`, I think it has the s= ame
> behavior than reading a file "literally" ?

Yes.

> Is there anything else we could do to improve the performance from
> reading the process output ?

I don't know yet, let's first try to solve the issue below:

> Now the problem is how can we have the same performance with a regular=
> emacs setup than with emacs -Q ?
> With my emacs setup, I have this result:
>
> (with-current-buffer (find-file-noselect "large.json" nil t)=
>=C2=A0 =C2=A0(benchmark-run 10 (json-parse-string (buffer-string)))) > ;;; (1.515018996 10 0.5256668049999996)
>
> (with-current-buffer (find-file-noselect "large.json" nil t)=
>=C2=A0 =C2=A0(let ((str (buffer-string)))
>=C2=A0 =C2=A0 =C2=A0(benchmark-run 10 (with-temp-buffer (json-parse-str= ing str)))))
> ;;; (1.156755376 10 0.5596599300000001)
>
> This is almost 2x slower than with emacs -Q.
> Note that there is still a difference with and without `with-temp-buff= er`.
> What can we do to reach emacs -Q performance ?

I think the only sure way is to find the customization(s) which are
responsible for the slowdown.=C2=A0 First, use find-file-literally, and if<= br> that doesn't help, bisect your customizations to find which one(s)
cause this two-fold slowdown.

Once you identify the customizations responsible for the slowdown, we
could then try to figure out whether that is due to some bugs or not,
and if the latter, then how to avoid the slowdown even with those
customizations in effect.

Thanks.
--0000000000007359f70584c2fed6--