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 17:27:58 +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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006545130584c49ec0" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="180113"; 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:04:17 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 1h7j85-000khm-KH for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 17:04:17 +0100 Original-Received: from localhost ([127.0.0.1]:45131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7j84-0004AM-Ig for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Mar 2019 12:04:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7j7B-0003VO-QA 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 1h7iz9-0004Ga-8G for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 11:55:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42168) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h7iz8-0004GS-Vy for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 11:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h7iz8-00079E-Uw for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2019 11:55: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 15:55: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.155335645427396 (code B ref 31138); Sat, 23 Mar 2019 15:55:02 +0000 Original-Received: (at 31138) by debbugs.gnu.org; 23 Mar 2019 15:54:14 +0000 Original-Received: from localhost ([127.0.0.1]:55710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7iyL-00077j-Nx for submit@debbugs.gnu.org; Sat, 23 Mar 2019 11:54:14 -0400 Original-Received: from mail-qt1-f178.google.com ([209.85.160.178]:41223) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7iZD-0006US-5H for 31138@debbugs.gnu.org; Sat, 23 Mar 2019 11:28:15 -0400 Original-Received: by mail-qt1-f178.google.com with SMTP id w30so5814490qta.8 for <31138@debbugs.gnu.org>; Sat, 23 Mar 2019 08:28:15 -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=3X1cWP2L6EKw/zsUIqu4YI09MW+XglQ+l1nJlmmmNFw=; b=NWRwBEKX5nKkqZaYDFtM3nVfzUOZbA7zmMv9l7YIOiFQHPN7iXPCBXyUx1ZISj/hsA Py9zAnHUiUBgU8HK20xRx+dW+RRizW0pdgzuW8M5SISwyZ/R4ScHHhvdHPaYIMegRhTA x0BweRK8NHIoR4n9FSAMN47/ospIx4dLz499tuseTg0wLcCBV8zcVm+k8W21kbfbuwIj Ej2q/00Xq2dhvUa8U4/wftkRHKFQtOcSl+NQfVnoTZQV62UEQ2LD9KVhqu+cSB8GJBsR 6e3I+nfHEj8+qbnwZhPaO9DWA/SI4x63dmLgBQBqD+e/V1w+bqLmGIy/ssvhLRNQHTtv z6Dw== 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=3X1cWP2L6EKw/zsUIqu4YI09MW+XglQ+l1nJlmmmNFw=; b=YN+cMihQ5cEWnDdkqpxDm1l1+xXV8/E6HosHFwus0rLggHBLApamclbQOd8MnpJ4tu dAMVpfQ7fRSE8vbGR2QEHkAFaM1VOoYA2UPql3/oPi4zn9kdQK8mHfWNcbkZI/7eSx+g r9Xk8BNCkaYDYltB48CWqrbM3jWU8jY+7Ls9rLTTGVS/GVxp6epM6ubbKRDWW1ZF7Syg d6iYeRE2mIJc1KZCByFr/xKhWJj/76lOnT+yi8GhhyMta6JTR36nxNzSJj39H9CAG40m wNMWCeyCUitXfq8TBGJyU58iHm/W9UYXh4zX6ICzIjsvdUpDNLwGCKFdrk1qo9JveLVh 1Ftw== X-Gm-Message-State: APjAAAWTTfgEJ0e2vcnn8heVjyO3ujIMJ5jo6gZryNyGEnhhhAgnA+dK L/VfkGw2CDiI/zpkwhuak1Om6Q4oeTnbIDm9FMg= X-Google-Smtp-Source: APXvYqxsASS2Bl6g88yaniVUh44NcC6n/ShsBDYDSuMD2o9CC6et0i+UJxF7BntF9EXKwmxKSLTwCuKodIMjE+lrlTw= X-Received: by 2002:a0c:89f3:: with SMTP id 48mr13353608qvs.215.1553354889445; Sat, 23 Mar 2019 08:28:09 -0700 (PDT) In-Reply-To: <83ftrdprmj.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:156670 Archived-At: --0000000000006545130584c49ec0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eli, > 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. Thanks, Ivan On Sat, Mar 23, 2019 at 4:55 PM Eli Zaretskii wrote: > > From: yyoncho > > Date: Sat, 23 Mar 2019 16:32:48 +0200 > > Cc: S=C3=A9bastien Chapuis , > > 31138@debbugs.gnu.org > > > > 6. At this point, my/call-counter is 32982 which means that > json-parse-string has triggered 32982 calls to > > my/test-query-function . I would add also that the number of strings in > the json file that I am using is exactly > > 32982 so I suspect that the issue is related to json_make_string . > > OK, but why is that a problem? > > > Here it is the output of from single invocation of json-parse-string - > > https://gist.github.com/yyoncho/101a87260b407d9f327b24c72ab15a92 - as > you can see there are numerous > > elisp functions invoked under json-parse-string. > > What I see in the profile is this: > > . json-parse-string takes the lion's share of the CPU time, which is > expected; > . some byte-compiled function takes another significant portion of > CPU time; to see what function is that, load the relevant Lisp > code from a .el file, instead of from .elc file, then re-run the > profile > > > What I am unable to provide is a minimal example so you could reproduce > this behaviour on your side using > > emacs -Q. > > Actually, I'm not yet sure what to reproduce. I'm probably missing > something. > --0000000000006545130584c49ec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli,

> OK, but why is that = a problem?

It makes native json=C2=A0parsing slower = than the elisp parsing and it is unclear why do we get these calls in the p= erformance critical section of the code(at least for lsp-mode) and it is un= clear how to avoid them. Without such recipe or a code fix native json=C2= =A0parsing will be unusable in combination with any package that attaches y= et to be defined extension point.=C2=A0

Thanks,
Ivan

On Sat, Mar 23, 2019 at 4:55 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: yyoncho <yyoncho@gmail.com>
> Date: Sat, 23 Mar 2019 16:32:48 +0200
> Cc: S=C3=A9bastien Chapuis <sebastien@chapu.is>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A031138@debbugs.gnu.org
>
> 6. At this point, my/call-counter is 32982 which means that json-parse= -string has triggered 32982 calls to
> my/test-query-function . I would add also that the number of strings i= n the json file that I am using is exactly
> 32982 so I suspect that the issue is related to json_make_string .

OK, but why is that a problem?

> Here it is the output of from single invocation of json-parse-string -=
> https://gist.github.com/yyoncho= /101a87260b407d9f327b24c72ab15a92 - as you can see there are numerous > elisp functions invoked under json-parse-string.

What I see in the profile is this:

=C2=A0 . json-parse-string takes the lion's share of the CPU time, whic= h is
=C2=A0 =C2=A0 expected;
=C2=A0 . some byte-compiled function takes another significant portion of =C2=A0 =C2=A0 CPU time; to see what function is that, load the relevant Lis= p
=C2=A0 =C2=A0 code from a .el file, instead of from .elc file, then re-run = the
=C2=A0 =C2=A0 profile

> What I am unable to provide is a minimal example so you could reproduc= e this behaviour on your side using
> emacs -Q.

Actually, I'm not yet sure what to reproduce.=C2=A0 I'm probably mi= ssing
something.
--0000000000006545130584c49ec0--