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 14:47:39 +0200 Message-ID: <83h6yilyfo.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3109"; 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 13:48:19 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 1p0027-0000Zq-I0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Nov 2022 13:48:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p001s-00074W-2r; Tue, 29 Nov 2022 07:48:04 -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 1p001q-00074O-UZ for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 07:48:03 -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 1p001q-0004QQ-KW for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 07:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p001q-00025n-I0 for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 07:48: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 12:48: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.16697260448035 (code B ref 56682); Tue, 29 Nov 2022 12:48:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 29 Nov 2022 12:47:24 +0000 Original-Received: from localhost ([127.0.0.1]:54427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0017-00025V-0f for submit@debbugs.gnu.org; Tue, 29 Nov 2022 07:47:23 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0013-00025O-Dw for 56682@debbugs.gnu.org; Tue, 29 Nov 2022 07:47:15 -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 1p000x-0004Ku-RU; Tue, 29 Nov 2022 07:47:07 -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=l4EQ604gcMVOSYm4a6l+LcOTM1xhJq17IcFQAy7EE6o=; b=kLfxDn8ZLRAQ 6G4JitySUlDGzzqm8uitQiC3AsRRDXjgfSVSIPWvJbt0zRKxa3mKG2AVivARzzMQnycFNlhgea7f9 s4dJLE/pl021VyxJ94PF0SZI3fkdx1BiCp0t+nzt1gUwljTKBSru9xc9cwXZAWvPEfAEF31WS2Zh4 8zIwaaKdQutsZJNBfWNHIhntxK9OhSxih0Ppo7Gb3vAR641pc0S5H1otBs0S1KtY1OIyaZWI09UuG C9SO4AvLl9jRsGJ6/j+VK14RKyGoHPx16VayI1+k4En2brJT7zxDzJ/xO0rO2WdxzOYGtV7CSbs2w 9lWzaf9lYmWZ6khXyViudg==; 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 1p000x-00054S-6q; Tue, 29 Nov 2022 07:47:07 -0500 In-Reply-To: (message from Dmitry Gutov on Tue, 29 Nov 2022 05:20:30 +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:249392 Archived-At: > Date: Tue, 29 Nov 2022 05:20:30 +0200 > Cc: Eli Zaretskii , Stefan Monnier , > 56682@debbugs.gnu.org > From: Dmitry Gutov > > Another thing that bothered me when testing: going from eob to bob in > dictionary.json took ~4 seconds every time, independent of buffer being > edited or not. And that delay didn't show up anywhere in the profiler. > (setq bidi-inhibit-bpa nil) didn't help at all, but (setq > bidi-display-reordering nil) eliminated that delay. So I'm still kind of > puzzled why we bother to restrict font-lock, but didn't do that with > this significantly more costly computation. 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. > Even with with common setup (and emacs -Q): > > 1. (setq long-line-locked-narrowing-region-size 50000) > 2. (setq bidi-display-reordering nil) > 3. Toggle show-paren-mode off, just in case. > 4. electric-pair-mode off, same. > > typing in the latter file exhibits random pauses in redisplay up to 0.5s > (and sometimes 1s+). I haven't managed to catch the exact source of > those pauses (and they're longer with my personal config), but even > regular editing is slower: evaluating > > (benchmark 1 '(progn (insert " ") (redisplay t))) > > in dictionary.json reports something like 0.038906s, but in > dictionary-pp.json it prints ~0.136387s. It is wrong to discuss here issues that are evidently unrelated to long lines and the measures to make Emacs more efficient with long lines. Please file a separate bug report about the delays you see, and please post there the file dictionary-pp.json you used in these tests. Bonus points for including in the report buffer positions where "typing exhibits random pauses in redisplay", to make search for those more efficient. Last, but not least: the "optimizations" (I prefer to call them "shortcuts") which we installed for making Emacs more responsive with long lines are just that: shortcuts. They deliberately ignore certain possible complications in buffer text and properties/overlays, and bypass the potentially costly code which handles them, in order to make the display code significantly faster, at a price of being less accurate and correct. So I'm not surprised that you sometimes see faster redisplay with long lines: it could well be due to these simplifications -- and the price is that in some situations the display will be incorrect. So it could turn out that there's nothing wrong with the "unoptimized" redisplay: it simply sometimes takes time to do all that it has to do to produce correct display on the screen. The resulting loss of accuracy and/or correctness is IMO justified when lines are so long as to make Emacs unusable without these shortcuts, but not when Emacs can cope with the complete and accurate display perfectly well, albeit somewhat slower. So you might be basically comparing apples with oranges here. But that is theory: we need specific recipes to investigate the causes for the delay. > Commit 89a10ffc (before the last merge) behaves the same, but going > further back, this commit from July behaves differently: b283e36cf19. > > Emacs built from that version reports ~0.033022s in dictionary-pp.json > and 0.114781s at bob in dictionary.json (scrolling to the end > predictably freezes that Emacs build). I don't understand what exactly you timed here (since it cannot be scrolling to eob). Is it the "insert one SPC" or is it something else? 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?