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: Thu, 01 Dec 2022 23:14:40 +0200 Message-ID: <83bkomhlmn.fsf@gnu.org> References: <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> <97049541-f5b4-ed3b-b8de-7c0bdc86f0f5@yandex.ru> <6e305c9b-7702-133a-3347-f64db05ade3f@yandex.ru> <83mt89kt10.fsf@gnu.org> <834juglesn.fsf@gnu.org> <83r0xkjw5s.fsf@gnu.org> <83pmd3ioxx.fsf@gnu.org> <47153506021498df087c@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36630"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 01 22:16:08 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 1p0qud-0009Iw-TU for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Dec 2022 22:16:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0quZ-0001Ed-R4; Thu, 01 Dec 2022 16:16:03 -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 1p0quY-0001B9-O6 for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 16:16: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 1p0quX-0003Jz-SH for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 16:16:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0quX-0001se-Nh for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 16:16:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Dec 2022 21:16: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.16699293187207 (code B ref 56682); Thu, 01 Dec 2022 21:16:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 1 Dec 2022 21:15:18 +0000 Original-Received: from localhost ([127.0.0.1]:41967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0qtp-0001sB-MP for submit@debbugs.gnu.org; Thu, 01 Dec 2022 16:15:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0qtm-0001s0-K0 for 56682@debbugs.gnu.org; Thu, 01 Dec 2022 16:15: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 1p0qtg-0001XL-Ec; Thu, 01 Dec 2022 16:15:08 -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=BYfLgBodxsNupGPDZTDVDVGuvc/RbnHs7jjwCrwsQGU=; b=RhIOyDgVbSuJ x0xfPToS/CCASyVCw0bMTb7ZJRT+JaIcHzOmGyhTyQQjSja7vH89Gvpi8yfKK5ZPD4YucTciMeHd+ HIxIl/k5oX5GcuMXmgX+cN2Kad5Xw1Ro7I0vLV525RAP3F6zN0gR77wvXoxhpuNTt2dMjrYBdHw4c 0S4tQuFjYYVA2rptivEEY+KWd6PdTXUsSqLqMllyyFET72k/FTGlqrBHARQL6hLw7nmPzjji9NDlj dhgWl+XDc4UFAqgw9PV+dPD0vH52GtMd51H5vx+iKtjw89CHcWWALqqvKkdzGL+DbdkzsTeQWJSJG Ryw0aQAhlWexroIawvi0tg==; 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 1p0qtf-0003lN-RI; Thu, 01 Dec 2022 16:15:08 -0500 In-Reply-To: <47153506021498df087c@heytings.org> (message from Gregory Heytings on Thu, 01 Dec 2022 20:49:18 +0000) 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:249671 Archived-At: > Date: Thu, 01 Dec 2022 20:49:18 +0000 > From: Gregory Heytings > cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru > > 1. M-: (let ((large-file-warning-threshold nil)) (find-file "dictionary.json") (narrow-to-region 4000000 4004000)) RET > 2. C-x n w > 3. Kaboom! By "Kaboom!" you mean what? a crash? Because it doesn't crash here. This is a build from the latest emacs-29 branch. > As far as I can tell, there are two possible ways to catch such > situations: > > 1. The first one is to _not_ use a heuristic, and to check in _each_ > redisplay cycle whether a certain portion of the buffer around point > contains long lines. This adds a fixed cost to all calls to redisplay, > which four months ago did not seem TRT to do. > > 2. The second one is to use a heuristic, which is what we do now, and to > check from time to time, when the buffer contents have changed "enough", > whether the buffer now contains long lines. When the buffer is edited > with small changes between each redisplay cycle, which is what happens in > the vast majority of cases, using that heuristic adds _no_ cost whatsoever > to calls to redisplay. The cost is added to only a few calls to > redisplay, and it is not fixed anymore, it is more important for a large > buffer than for a small one. Doing that seemed TRT four months ago. This is all beyond argument. We do want the heuristic. I just want it to be cheaper than it is now, especially for buffers without any long lines, where each time we run this loop we waste CPU cycles. So I'm looking for ways of wasting less of them. > > That benchmark is an example of many use cases that can happen in real > > life, in a large buffer with no long lines and a lot of editing > > activity. I'm surprised you don't see it. > > I don't see it, indeed. And I'm surprised that nobody complained about it > during the last four months. Very large buffers are relatively rare, so I'm not surprised we didn't hear about this until now. But it is very easy to come up with a situation where this happens, so we don't need to wait for complaints to know that they can exist. > Do you have a recipe with which I could see that effect? I just tried to > edit dictionary-pp.json "heavily" (large kills and yanks), and Emacs > remained responsive, I did not experience any hiccups. Edit large enough buffer, and the time it takes to run the loop which scans the entire buffer will eventually cross the threshold of human perception. dictionary-pp.json is just 28MB, which is not large enough. Make a 500MB file or even 2GB file, and I think you will see the effect. Better yet, time the loop for a large enough buffer, and we will be able to estimate the time it takes for arbitrary buffer sizes with "reasonable" line length, because that loop scales approximately linearly with the buffer size and the number of newlines. > > The main issue at hand is how to avoid needless scanning of the entire > > buffer for long lines, something which doesn't scale well with buffer > > size. For very large buffers without any long lines, this is a > > regression in Emacs 29, because Emacs 28 didn't do that. IOW, we make > > "good" buffers suffer because of the (rare) danger presented by > > potentially "bad" buffers. We need to look for ways of making this > > degradation as small and as rare as possible. > > Yes, it's a compromise. As I explained above, the only other possible > compromise that is safe enough is to make _all_ buffers "suffer" (but > suffer less). I'm trying to find a better compromise, in the hope that one exists. No more, no less.