From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56682: locked narrowing Date: Tue, 29 Nov 2022 16:25:01 +0200 Message-ID: <835yexn8hu.fsf@gnu.org> References: <831qtgff78.fsf@gnu.org> <83zgg4dw4y.fsf@gnu.org> <83r11gdrr4.fsf@gnu.org> <83edxfds7s.fsf@gnu.org> <83r11fc80o.fsf@gnu.org> <83o7wjc6o2.fsf@gnu.org> <83lernc5gu.fsf@gnu.org> <83k076dd7d.fsf@gnu.org> <83czcyd8jf.fsf@gnu.org> <83a682d66r.fsf@gnu.org> <837d36ceno.fsf@gnu.org> <37dd2827f54f8bbda5e3@heytings.org> <735c1d5b-0d64-a8e1-3aaa-91fc0248abd3@yandex.ru> <83h6yilyfo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22739"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 29 15:25:29 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p01Y8-0005ky-JK for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Nov 2022 15:25:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p01Xo-0000e0-H0; Tue, 29 Nov 2022 09:25:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p01Xi-0000c9-Q7 for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 09:25:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p01Xi-0006YS-FY for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 09:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p01Xi-00032S-Bo for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 09:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2022 14:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.166973187911659 (code B ref 56682); Tue, 29 Nov 2022 14:25:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 29 Nov 2022 14:24:39 +0000 Original-Received: from localhost ([127.0.0.1]:54548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p01XL-00031z-B8 for submit@debbugs.gnu.org; Tue, 29 Nov 2022 09:24:39 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p01XJ-00031h-3K for 56682@debbugs.gnu.org; Tue, 29 Nov 2022 09:24:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p01XB-0006Rc-RU; Tue, 29 Nov 2022 09:24:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/HgEysvV8VEV8ntBeY8DEM0yMWRkrkC4KiIC9opQNyM=; b=AUhf1T4/QYgk nvy2vEQBd/K3LwUIX5euAWsEHDGjyh3qdYXIvva6mxa83tp3Qo6Sd8HlSEoxtVd+PBkaPHxUEJdNg KvgB13WII0C0wCI6MZqPdApNtxxxuXS8kS7GV9QRE4Lle3Qk+GMsmTsMTG3V6QFsvMeX/N8S68EcG Dq1IeyBH7kL9ZdT3cd3HwxUp3aXQTlHYOdrM91qM7D7gVq0k2UeGEdh/9Kg9Suh01QfGL8iXepQLQ EP9rqTuTjZAEWvOkfO/h46ZvizgpFMKH+jL/m/j1mqS4/kRzEiqrnOt0AV5QN3el0LiGLGttp11E7 RniISIVBO84H25SwXWi/rw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p01XB-00086v-9e; Tue, 29 Nov 2022 09:24:29 -0500 In-Reply-To: (message from Dmitry Gutov on Tue, 29 Nov 2022 15:21:12 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249402 Archived-At: > Date: Tue, 29 Nov 2022 15:21:12 +0200 > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca > From: Dmitry Gutov > > > Why do you think we didn't restrict them? Limitations on costly > > bidi-related stuff is in Emacs since the very beginning, in v24, AFAIR. And > > no code in bidi.c or xdisp.c ever goes outside the current narrowing. > > Just because it was really slow. Apologies, I seem to be unable to > reproduce this effect now. I'll get back to this if I see it again. What is not reproducible? the 0.5sec delays or something else? Is it still worth our while to look at the dictionary-pp.json file and the slow redisplay with it? > dictionary-pp.json is produced from dictionary.json using 'M-x > json-pretty-print-buffer'. It's 27 MB long, do you want me to upload it > to some file sharing platform? If you compress it with xz, doesn't become small enough to post here? If not, please upload somewhere and tell where. > The profiler output looks like this: > > 526 87% - command-execute > 516 85% - call-interactively > 378 62% - funcall-interactively > 370 61% - eval-expression > 370 61% - eval > 370 61% - benchmark > 370 61% - benchmark-call > 194 32% - # > 194 32% - progn > 194 32% redisplay > 160 26% - # > 160 26% - progn > 160 26% redisplay > 16 2% - # > 16 2% - progn > 16 2% redisplay This seems to say redisplay takes about 1/3rd of the time? > > In any case, 0.114781s just 19% (and 22 msec) slower than 0.136387s, so is > > this something serious to talk about? There could be any number of reasons > > for this, including some changes to the JSON mode, perhaps? > > It's 0.114 vs 0.033 (in dictionary-pp.json, file without long lines). I thought you were saying that Emacs at commit 89a10ffc and at current HEAD took 0.136387 sec, which is slower than 0.114 sec at commit b283e36cf19 (from July)? The 0.033 figure is with long-line optimizations, no? So it's a very different buffer text and different code paths.