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 22:23:49 +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> <83k1gppu73.fsf@gnu.org> <83ftrdprmj.fsf@gnu.org> <83d0mhpn99.fsf@gnu.org> <83zhplo25s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006d4a840584c8c08a" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="209666"; 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 21:33:23 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 1h7nKU-000sQE-QH for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 21:33:23 +0100 Original-Received: from localhost ([127.0.0.1]:47764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7nKT-0002dl-NA for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 16:33:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7nKD-00029O-V7 for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 16:33:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7nCQ-0005DD-Ku for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 16:25:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42259) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h7nCQ-0005D3-HM for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 16:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h7nCQ-0005MV-41 for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 16:25:02 -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 20:25:02 +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.155337264920544 (code B ref 31138); Sat, 23 Mar 2019 20:25:02 +0000 Original-Received: (at 31138) by debbugs.gnu.org; 23 Mar 2019 20:24:09 +0000 Original-Received: from localhost ([127.0.0.1]:55803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7nBY-0005LI-Tl for submit@debbugs.gnu.org; Sat, 23 Mar 2019 16:24:09 -0400 Original-Received: from mail-qt1-f182.google.com ([209.85.160.182]:47023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7nBX-0005Ks-2P for 31138@debbugs.gnu.org; Sat, 23 Mar 2019 16:24:07 -0400 Original-Received: by mail-qt1-f182.google.com with SMTP id z17so6238902qts.13 for <31138@debbugs.gnu.org>; Sat, 23 Mar 2019 13:24:07 -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=BEsL1FaFC0QPJvcJ8r4GYTRxlOMeNSyhKKmv2WmLi1E=; b=KwoyDXrRAYE4B+vayFXcM7YbibgFA3euDAgRWCUpunj7f61VwCk+wWz1pDCqNc0R5u n8f9JUrnd9DwwJVPXRamj8N9AK0+mtKFObyseWVpmC5tgsjPVDjlkYmb95XuKCGSok9D 0QueimTtrKALFtBRk7Yjp0fs5eiCBzSSJ4L3IKIM5bIfY+m5Dxvbr8/ILil2LL+n/Lry zuWDX5UjJbdqLEu/GF6QiwG8jMgF4YaidzXTIpt+rNgKGobh7JFf6KDmdPYdimsTBHa4 0Q9mm2VsNRyDI9EXpQB6sizFxiQUmsKXod86sOaptR+bByhj2cl46vS099sGqbM/J+M6 v7TQ== 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=BEsL1FaFC0QPJvcJ8r4GYTRxlOMeNSyhKKmv2WmLi1E=; b=Ebad/FzLc8/eviqllpdCRiKroq51zNM+gGauaejVt/ZuakxJ3D3ukNrQrEJvQuPtVz FlyE6wDArz1tJwqQNf0NnCVrxT9tJZs+iVAti9BMst6Qmb2JCV/qQjuYvFimeMcOTuvY U9xHSezHgWHXPQFW5nkvwCaNNLzjpdDPpCdCaLiNgptxhxLo6wTOCeWlu2EROJADn9nU QIknLAor3hUoKMTt4eUvEqJPsa+SfxomP+isyzorKSLqHqy6cI+eiOAr80TwPz08V4/v UFzSkuECkQze0Nt2GMEam54G8pZMtf9clT/nHRrumpkIPlBeB0rXUxO+bJxKbtel2Bgv wYhg== X-Gm-Message-State: APjAAAUbqQTONPxF1DmYUZpgjMjNSy9xHH4LRBKVgIUKREEcTjLQoAtl Y48grZ5qRzJi7uo8klJKCb2G0YGDRV9c31FZ5Ak= X-Google-Smtp-Source: APXvYqy1lZzwJoGWW0IdDQluu9apAZ+Pz6Ve6GBVeDolgDCspp/v1g1zeEIRU02VhKDJo4Pg/u3fNUS+QdvCb6bTMYI= X-Received: by 2002:a0c:814d:: with SMTP id 71mr3767037qvc.47.1553372640265; Sat, 23 Mar 2019 13:24:00 -0700 (PDT) In-Reply-To: <83zhplo25s.fsf@gnu.org> 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:156679 Archived-At: --0000000000006d4a840584c8c08a Content-Type: text/plain; charset="UTF-8" Hi Eli, Here it is the offending callstack. https://gist.github.com/yyoncho/7032464b456f60270100c747f42885f8 Thanks, Ivan 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"? > I am also unable to reproduce it with "emacs -q", even it works fine right after I start my Spacemacs based configuration. It happens after some time on my system. > > 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. > This does not work since apparently when the breakpoint is hit the > > 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. > --0000000000006d4a840584c8c08a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli,

Her= e it is the offending callstack.=C2=A0

<= br>
Thanks,
Ivan


However, I c= annot reproduce what you describe, not with the latest
Emacs master bran= ch.=C2=A0 When I repeat the recipe you posted in

=C2=A0 https://gist.github.com/y= yoncho/9e9c4e14734fdd9a22d6600a88a27ae1

I get zero as the final value of the counter, not 32982.=C2=A0 As I'= ;d
expect, as I don't see why kill-buffer-query-functions would be c= alled
in this scenario.=C2=A0 This was in "emacs -Q", do you g= et a non-zero count
even in "emacs -Q"?
<= br>
I am also unable to reproduce it with "emacs -q", e= ven it works fine right after I start my Spacemacs based configuration. It = happens after some time on my system.=C2=A0
=C2=A0

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

=C2=A0 . Modify the above recipe to call 'message' inside
= =C2=A0 =C2=A0 my/test-query-function.
=C2=A0 . Run Emacs under GDB after= putting a breakpoint in Fmessage (this
=C2=A0 =C2=A0 is the C name of &= #39;message').
=C2=A0 . Run your recipe.=C2=A0 When the breakpoint i= n 'message' breaks, display
=C2=A0 =C2=A0 the Lisp backtrace usi= ng the "xbacktrace" command (it is defined
=C2=A0 =C2=A0 in sr= c/.gdbinit in the Emacs source tree).

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

This does not work since apparently when the breakpoint is hit the=C2= =A0
=C2=A0

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

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

Here are a few:

=C2=A0 http://www.brendangregg.com/perf.html
=C2=A0 = https://perf.wiki.kernel.or= g/index.php/Tutorial#Sampling_with_perf_record
=C2=A0 https://perf.wiki.kernel.org/index= .php/Tutorial#Sample_analysis_with_perf_report

The perf man pages are also useful.
--0000000000006d4a840584c8c08a--