From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#31138: Native json slower than json.el Date: Sat, 23 Mar 2019 20:50:55 +0200 Message-ID: <83zhplo25s.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="64902"; mail-complaints-to="usenet@blaine.gmane.org" Cc: sebastien@chapu.is, 31138@debbugs.gnu.org To: yyoncho Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 23 19:52:13 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 1h7lkZ-000Ghw-2x for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 19:52:11 +0100 Original-Received: from localhost ([127.0.0.1]:46702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7lkX-0000dB-Uw for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 14:52:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7lkR-0000d3-MT for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 14:52:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7lkQ-0000nf-HE for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 14:52:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42242) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h7lkQ-0000nP-Ay for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 14:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h7lkQ-0003Bt-0j for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 14:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Mar 2019 18:52: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.155336710912243 (code B ref 31138); Sat, 23 Mar 2019 18:52:01 +0000 Original-Received: (at 31138) by debbugs.gnu.org; 23 Mar 2019 18:51:49 +0000 Original-Received: from localhost ([127.0.0.1]:55786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7lkD-0003BN-34 for submit@debbugs.gnu.org; Sat, 23 Mar 2019 14:51:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7lkB-0003B9-CM for 31138@debbugs.gnu.org; Sat, 23 Mar 2019 14:51:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7lk5-0000Ss-EP; Sat, 23 Mar 2019 14:51:41 -0400 Original-Received: from [176.228.60.248] (port=4812 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7lk1-0005vD-Nj; Sat, 23 Mar 2019 14:51:41 -0400 In-reply-to: (message from yyoncho on Sat, 23 Mar 2019 20:03:29 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:156677 Archived-At: > From: yyoncho > 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.