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 15:21:12 +0200 Message-ID: <83lg15pvzr.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> 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="49910"; mail-complaints-to="usenet@blaine.gmane.org" Cc: yyoncho@gmail.com, 31138@debbugs.gnu.org To: =?UTF-8?Q?S=C3=A9bastien?= Chapuis Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 23 14:22:21 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 1h7gbK-000Cio-FP for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 14:22:19 +0100 Original-Received: from localhost ([127.0.0.1]:43460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7gbE-00080d-8t for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 09:22:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7gb5-0007zS-FU for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 09:22:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7gb4-0007vR-BF for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 09:22:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41522) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h7gb4-0007v5-5H for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 09:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h7gb3-0003IF-Tx for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 09:22:01 -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 13:22: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.155334728412604 (code B ref 31138); Sat, 23 Mar 2019 13:22:01 +0000 Original-Received: (at 31138) by debbugs.gnu.org; 23 Mar 2019 13:21:24 +0000 Original-Received: from localhost ([127.0.0.1]:55066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7gaR-0003HD-HI for submit@debbugs.gnu.org; Sat, 23 Mar 2019 09:21:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7gaP-0003H1-5V for 31138@debbugs.gnu.org; Sat, 23 Mar 2019 09:21:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7gaJ-0006Dl-7X; Sat, 23 Mar 2019 09:21:15 -0400 Original-Received: from [176.228.60.248] (port=4089 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7gaI-0004uV-Bk; Sat, 23 Mar 2019 09:21:14 -0400 In-reply-to: (message from =?UTF-8?Q?S=C3=A9bastien?= Chapuis on Sat, 23 Mar 2019 20:59:46 +0800) 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:156659 Archived-At: > From: Sébastien 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.