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: Mon, 22 Apr 2019 10:03:59 +0300 Message-ID: <83ftqa8qsg.fsf@gnu.org> References: <87sh806xwa.fsf@chapu.is> <83d0mgnn31.fsf@gnu.org> <835zs7och6.fsf@gnu.org> <83tvfqnbxc.fsf@gnu.org> <83lg12n75s.fsf@gnu.org> <83h8bqn2ik.fsf@gnu.org> <83zhphliil.fsf@gnu.org> <181b93a3-3861-0481-1b95-8344410d1049@yandex.ru> <83r2a2hdxn.fsf@gnu.org> <21f68973-a684-2a65-82eb-c8f3df90127f@yandex.ru> <83d0lmgez2.fsf@gnu.org> <7d503be9-4d85-3d0b-6829-631ad376ba3d@yandex.ru> <831s22gcci.fsf@gnu.org> <83y349gasn.fsf@gnu.org> <83d0lfag4x.fsf@gnu.org> <5cf45a21-65c3-67ee-f123-be83a6ee7c99@yandex.ru> <83a7gjaen6.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="6229"; mail-complaints-to="usenet@blaine.gmane.org" Cc: sebastien@chapu.is, yyoncho@gmail.com, 31138@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 22 09:09:53 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 1hIT5M-0001Ua-Gd for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Apr 2019 09:09:52 +0200 Original-Received: from localhost ([127.0.0.1]:33460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIT5L-00031w-CO for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Apr 2019 03:09:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIT0h-0007v3-PS for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 03:05:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIT0g-0006RH-Lq for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 03:05:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36086) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hIT0g-0006Qx-Io for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 03:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hIT0g-0001In-8s for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 03:05: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: Mon, 22 Apr 2019 07:05: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.15559166594944 (code B ref 31138); Mon, 22 Apr 2019 07:05:02 +0000 Original-Received: (at 31138) by debbugs.gnu.org; 22 Apr 2019 07:04:19 +0000 Original-Received: from localhost ([127.0.0.1]:49630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hISzz-0001He-Bp for submit@debbugs.gnu.org; Mon, 22 Apr 2019 03:04:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43539) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hISzx-0001HS-Ox for 31138@debbugs.gnu.org; Mon, 22 Apr 2019 03:04:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hISzr-0005ji-Rn; Mon, 22 Apr 2019 03:04:11 -0400 Original-Received: from [176.228.60.248] (port=3628 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hISzp-0002M5-Ue; Mon, 22 Apr 2019 03:04:11 -0400 In-reply-to: (message from Dmitry Gutov on Mon, 22 Apr 2019 01:12:49 +0300) 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:157986 Archived-At: > Cc: sebastien@chapu.is, yyoncho@gmail.com, 31138@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 22 Apr 2019 01:12:49 +0300 > > On 21.04.2019 12:31, Eli Zaretskii wrote: > > >> Eli, how did you reach that conclusion? > > > > By adding the percentage of all the functions involved in decoding > > strings. > > Was the total sum of the profile 100%? Yes. Wasn't it 100% in your profiles? I think it was. > > I only accounted for time used by Emacs code, i.e. 100% doesn't > > include the library. > > I still don't understand. I my profiling report, decode_coding_utf_8 is > at the top (Emacs function). Followed by malloc and produce_chars. Are > you saying they are not involved in decoding strings? Part (roughly half) of produce_chars is, malloc mostly isn't. > > In any case, even if decoding takes 50% of the time we spend in Emacs > > code, it is still not significant enough to justify the un-safety of > > using a string that we didn't decode, because if that string ever > > includes raw bytes, Emacs will surely crash. > > What was the point of us doing the exercise, and me wasting time on it, > if you're set on not changing anything at all? If the percentage of the decoding was much higher, like 80% or 90%, say, then we would have a much better incentive to try to salvage at least some of that, than we have now. > We've already had the performance numbers from before. The percentage of time taken by decoding wasn't clear to me, so I wanted to profile. Mind you, I intended to do that myself, I didn't ask anyone to do it for me, although I'm of course grateful for your work on this, as it confirmed my results. > Given the encouragement, I really expected you to choose *some* path > toward improvement. Either forgoing conversion (maybe adding an > additional test suite, for cases you're worrying about), or doing some > kind of faster validation instead of full conversion (where we don't > allocate new strings but just check existing ones for validity), or, you > know, optimizing everything everywhere. If someone has ideas how to speed up decode_coding_utf_8, please speak up, and let's try that. AFAICS, it is already heavily optimized for the case of plain ASCII text, which is what we used in our profiling. If plain ASCII text is important enough, perhaps we could make this even faster, at the price of making non-ASCII cases slightly slower, by adding a function that just validates plain ASCII without producing a decoded string. The original bug report found that we do unnecessary stuff like allocating temporary buffers and calling various hook functions -- all that is now gone, so we definitely have sped this up, probably significantly in some non-"emacs -Q" cases. > Considering libjansson manages to do both JSON parsing and string > conversion in ~the same time make_specified_string only does string > conversion on the returned strings, it most likely follows that > make_specified_string could be made faster. FWIW, I have stream_get.part.3 in my profiles that takes almost twice the time as decode_coding_utf_8, and various lex_* and other functions also quite high on the profile, with 1.5% to 3.5%. So it isn't like libjansson is tenfold faster than our code.