From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#56682: locked narrowing Date: Tue, 29 Nov 2022 19:56:30 +0200 Message-ID: <97049541-f5b4-ed3b-b8de-7c0bdc86f0f5@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4043"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: 56682@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 29 18:57:30 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 1p04rJ-0000x8-Sk for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Nov 2022 18:57:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p04rD-0007D8-C1; Tue, 29 Nov 2022 12:57:23 -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 1p04qt-00071d-8w for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 12:57: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 1p04qs-0002ge-Cw for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 12:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p04qr-00056W-R9 for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 12:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2022 17:57:01 +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.166974460519611 (code B ref 56682); Tue, 29 Nov 2022 17:57:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 29 Nov 2022 17:56:45 +0000 Original-Received: from localhost ([127.0.0.1]:55428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p04qa-00056D-5t for submit@debbugs.gnu.org; Tue, 29 Nov 2022 12:56:44 -0500 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:37571) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p04qU-000567-SH for 56682@debbugs.gnu.org; Tue, 29 Nov 2022 12:56:42 -0500 Original-Received: by mail-wm1-f51.google.com with SMTP id ay14-20020a05600c1e0e00b003cf6ab34b61so15012937wmb.2 for <56682@debbugs.gnu.org>; Tue, 29 Nov 2022 09:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=mk9THzNZhyfLyV4ItUK4QEmQDhT+I/qEEHyoCH4qsLw=; b=HE/N4/wzbBCpzcOU06Ogh5XApBytHbgQseeACs4IoBiFgU6XWuqH4zDUyLdBI+X7sp W85R+c7TqM/Qce3Qx1Jq0pYborpU22SGk4bJC2kYWeR4x76LnB9eg07nEx3BxYZfSeR7 eJUpuc/Iv5+ssiLt21Y3Q/QxEN+vwlM2/P/meaymfH1+KaRFLO6XaN03PKcHqKJVloMw CNaARelv6k0LIIBVCOVTTDXrhqv9k63E+b+73yGyCTYWv6pVbVRlXOac12gJvYrxVlBI c70bmGfRKfChHZpv+RlPInNqYC0jFj/9KnnAzRZVYRMDNyqnx7fTqv7VElKJVINzrsui wc0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mk9THzNZhyfLyV4ItUK4QEmQDhT+I/qEEHyoCH4qsLw=; b=qweEU83YhTqdngwf7XhmEtYab3jw78+tgjevoPL2Y5VR/rkELecDv7XPcxZYjDkgH2 Gjqvl6JN2ZCkOJYUMeAs1Gfv4zvRYddLo+j9eQygNeCFoRGirmQBKYZf88QdtByHAY7G Yk0Cve7bRsgNowsHIL9YGbTeJDlNFePFeeCQ0TjTXv7PUAoMb1SfBQT2lcCkQUfkuDb9 IHSQPr3C7HTUefFCanysWjkI/asxkNhj0/T2kHlBgv6+9xjPnjyjHPxLNowuBrUBAEBo JneDqmsgrF85MxE5QuZwlP4VPfjHIxaUUm2sElgOqRArfJYwPECVLT4seapug3PyTk1x Ho6Q== X-Gm-Message-State: ANoB5pnzwXyUlWoovUAz5n+Mb/L6MxS2lgU2jvwZUbwNDnh2msvHNL/q +J+B8tvyu4K4GqtrdsZ1tZ4= X-Google-Smtp-Source: AA0mqf5TolKl1JI59CwYkYnz5GEASWe112gIBPAKKLWc6g5DC1ezjStI4G15Ne5hhf9lD/JmXFinIw== X-Received: by 2002:a1c:7318:0:b0:3cf:cb16:f24a with SMTP id d24-20020a1c7318000000b003cfcb16f24amr45248974wmb.182.1669744592857; Tue, 29 Nov 2022 09:56:32 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s11-20020a5d69cb000000b002366f9bd717sm16591188wrw.45.2022.11.29.09.56.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 09:56:32 -0800 (PST) Content-Language: en-US In-Reply-To: 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:249419 Archived-At: On 29/11/2022 19:10, Gregory Heytings wrote: >> Looking at the code, there is indeed some halving going on, so maybe >> it would be more easier to understand if the variable was called >> locked-narrowing-radius, and used as such -- without division. >> > > I considered naming it with "radius", but decided not to do it.  This is > an implementation detail.  And the docstring says "region around point", > from which an attentive reader can infer that half of the region will be > before and half of it will be after point.  It does not seem worth the > price to introduce separate cases for point at or near BOB and point at > or near EOB. All right. It would have been easier for me to understand, but it's nothing critical. >> 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. >> > > Your analysis is not correct: the delay you see is due to > show-paren-mode. Turn it off, and you'll see that going from EOB to BOB > is instantaneous. show-paren-mode does seem to have a tiny effect here, but nothing comparable. And when it's on, it seems to blink red (the "mismatch" face), indicating that its scan probably stops earlier before it reaches the EOB. Anyway, I'll let you know with more details when I see this again. Previously, I would see this effect (multi-second delays) every time I test the feature, now it is just gone. Maybe 'make bootstrap' helped. >> And we'll probably come back to this question sometime later, but >> here's something that looks like a regression. Editing dictionary.json >> is snappier than dictionary-pp.json (same file but pretty-printed so >> without long lines). >> > > Unless I misunderstand what you mean, this cannot be a regression: > editing dictionary.json was not possible with Emacs 28, editing > dictionary-pp.json was.  Even if the former were now snappier than the > latter, that would not be a problem in itself. I'm mostly talking about how editing dictionary-pp.json became slower. The fact that editing dictionary.json is now faster than that is, while counter-intuitive, definitely not something to complain about by itself. >> 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. >> > > I cannot reproduce that.  With emacs -Q, with dictionary-pp.json and > with show-paren-mode disabled, type C-s aan zich RET.  Now type some > text: in both cases the effect is near instantaneous here, and I do not > see any random pauses. Right. "aan zich" is not far from EOB. My scenarios are all near BOB. > With your benchmark and with dictionary-pp.json: > > - on current master, after C-s eman RET, I see ~100 ms, and after C-s Note the 100 ms. > aan zich RET, I see ~100 ms "eman" is near BOB for you as well, right? > - at ff57f30bee (30 July), after C-s eman RET, I see ~20 ms, and after > C-s aan zich RET, I see ~2700 (!) ms > > - at c59b8dfefa (30 Jun), after C-s eman RET, I see ~20 ms, and after > C-s aan zich RET, I see ~2700 (!) ms Note the 20 ms. > - with Emacs 28, after C-s eman RET, I see ~20 ms, and after C-s aan > zich RET, I see ~3000 (!) ms Yup, the long delays near EOB are expected, I fixed them in js.el not too long ago (one in font-lock rules, and anothing by creating js-json-mode). > With your benchmark and with dictionary.json: > > - with current master, after C-s eman RET, I see ~70 ms, and after C-s > aan zich RET, I see ~70 ms > > So there is no regression as far as I can see. Your observations seem to match mine. Look at the timings for dictionary-pp.json. After C-s eman: master: ~100 ms ff57f30bee, or c59b8dfefa, or Emacs 28: ~20 ms That's the regression. But like Eli said, it might be unrelated your code, it just seems to belong to the same general area. If my guess was wrong, I apologize.