bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked


From: Dmitry Gutov
Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.
Date: Tue, 31 Jan 2023 18:25:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 31/01/2023 17:14, Gregory Heytings wrote:


So we are removing all the stuff that prevented font-lock from slowing down redisplay when long lines are in the buffer?  IOW, something which we have for several months, and which so far brought up only one complaint?  Frankly, this makes no sense to me, unless we delay the pretest for another half year or so.  It's too late for such changes.

Or am I missing something?


I looked with a critical eye at the code I wrote, and concluded that the cure is worse than the disease.

It's true that some slowdowns caused by font-locking are prevented by locked narrowing, but:

1. The slowdowns caused by font-locking were not the major cause of slowdowns in buffers with long lines.  They were the "last step" to make editing operations in such buffers as fast as possible, and my opinion now is that that last step was a step too far.  Efficiency issues in font locking routines are the responsibility of mode authors. Efficiency issues in the redisplay routines are the responsibility of Emacs, and have been dealt with.

FWIW, I happy you reached that POV.

2. Locked narrowing does not prevent all slowdowns caused by font-locking.

3. Locked narrowing can create slowdowns (e.g. infinite loops) that do not exist when it is not present.

This could be a pretty good argument. When testing in larger files, I did notice some performance kinks I could not easily explain, nor stably reproduce.

Speaking of additional slowdowns, though, at least in theory -- both syntax-ppss and tree-sitter drop their current parse result when point-min changes. So it an already fully parsed buffer (which applies more often to tree-sitter, though), scrolling through the buffer and fontifying should cause caches to drop to be recomputed again when the narrowing changes. Though that particular effect might not be too noticeable, since those features are rather fast in a 50000 region.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]