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

[Dmitry Gutov]

On 07.08.2022 23:21, Gregory Heytings wrote:
> > > No, isearch is entirely agnostic about font locking.
> >
> > I wonder where it spends those 2 seconds, then.
>
> The answer is simple: it is not isearch that is slow, it's redisplay 
> that is slowed down by font locking.

Turns out, that was true. Unexpectedly, there was an area near the 
beginning of that file where a particular matcher (that I have now 
removed in fcd2d14db1) slowed things down considerably. The effect was 
such that fontifying a particular screen was about as slow as fontifying 
the end of the buffer.

That might or might not be a general design bug in font-lock with its 
MATCH-ANCHORED syntax (when a line is long, the "anchored" thing might 
lose its meaning).

isearch looks fast again, you're welcome to try.

> > > It's yet another test meant to test Emacs' responsiveness, and it is 
> > > as "objective" as possible: does Emacs choke or does it not?
> >
> > It's not a test of font-lock's performance, however. Because it 
> > compares that to a process that's internal to Emacs as well (moving 
> > across the buffer with C-v). Like, the faster we're able to make the 
> > latter command, the faster font-lock has to be to keep up. As an 
> > objective test, it's not meaningful.
>
> It is not by itself a test of font locking performance.  It becomes one 
> when you compare it with what you see (a) when font locking is 
> completely disabled, and (b) when font locking is enabled by constrained 
> by a locked narrowing.

What do you get from that comparison? That one thing is faster than the 
other? That accurate font-lock might take a little more time?

In any case, when I floor 'C-v' in dictionary.json now, whether 
narrowing is applied in 'handle_fontified_prop' or not, I see the buffer 
stutter around 2%, then go on and freeze around the 9% mark. When I 
release 'C-v' after waiting a while, it ends up at 12% or 14%.

Or if I go to EOB and floor 'M-v', both versions freeze almost right 
away. So it doesn't look like one is an order of a magnitude faster than 
the other, or at least not anymore.

C-n and C-p are also pretty sluggish with both versions.