bug#56682: Fix the long lines font locking related slowdowns

[Dmitry Gutov]

On 04.08.2022 04:26, Gregory Heytings wrote:

> > Here I'm attaching a version of downloadify.js we can use for 
> > comparison (please rename the extension from .sj to .js locally; Gmail 
> > was not letting it through otherwise). It's not a huge file, just 
> > about 88K.
>
> It's a tiny file, not in any way representative of the ones we're 
> dealing with.  But amusingly, even with that tiny file, you can see the 
> problem at hand.  Do M-: (setq long-line-threshold nil) RET, and open it 
> in a large enough window (e.g. 160 characters).  Type M->, and try to 
> move point there with C-p or C-n.  You'll see that Emacs is already 
> sluggish.

That's the scenario I described, and that's my point: this file's 
display is sluggish. Even though font-lock has already finished its 
work. And it didn't have to spend any significant time in syntax-ppss.

So there is a particular performance problem with the display of 
fontified buffers which I'd really like your help in fixing.

Fixing in a way that doesn't add narrowing around 
fontification-functions, because as we can see it's not necessary in 
examples like this.

Then it would be much easier to evaluate font-lock's effect on 
performance in larger files.

> > I'm also attaching a screenshot of another problem: suddenly the 
> > bottom several screens of the buffer are mis-highlighted as if 
> > starting inside a string. That very much look like a result of 
> > breaking syntax-ppss's visibility of the buffer.
> >
> > So the buffer scrolls quickly but looks bad.
>
> If you dislike mis-fontification, turn font-lock mode off.  It's as easy 
> as that.  Mis-fontification is expected in such cases.  The docstring of 
> syntax-wholeline-max also mentions that "misfontification may then 
> occur". Why did you not protest at that time?

I think we could have both speed and correctness, at least for files of 
this size.

> > Branch feature/long-lines-and-font-locking, revision cd41ce8c6c1079 
> > from July 25. That branch is not there anymore, so let me know if I 
> > should re-test this with some later version of your work.
>
> That branch doesn't exist anymore, it has been merged in master.

Thanks.