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

[Dmitry Gutov]

On 16.08.2022 05:33, Eli Zaretskii wrote:
> > Date: Mon, 15 Aug 2022 22:51:16 +0300
> > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > On 15.08.2022 19:58, Eli Zaretskii wrote:
> > > > Date: Mon, 15 Aug 2022 19:44:07 +0300
> > > > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> > > > From: Dmitry Gutov <dgutov@yandex.ru>
> > > >
> > > > > > Here's the profiler output anyway:
> > > > > >
> > > > > >             1067  85% - command-execute
> > > > > >             1067  85%  - call-interactively
> > > > > >             1023  82%   - funcall-interactively
> > > > > >             1012  81%    - end-of-buffer
> > > > > >             1008  81%     - recenter
> > > > > >             1008  81%      - jit-lock-function
> > > > > When did you last resync from Git?  'recenter' got "optimized"
> > > > > yesterday for buffers with long lines.
> > > >
> > > > Just today.
> > > >
> > > > In any case, it doesn't look like recenter's problem, since the output
> > > > says all (or vast majority) of its time is spent in jit-lock-function.
> > >
> > > AFAIU 'recenter' shouldn't at all call jit-lock-function in a buffer
> > > with long lines.  Is this "emacs -Q" without any changes from
> > > defaults?
> >
> > It's a buffer without long lines. Simply a large file.
>
> ??? Are we talking about long-line.xml, or are we talking about
> some other file?  We did nothing to change the behavior in large files
> without long lines.

I'm talking about a 20 MB file I created manually with some simple 
contents. Just no long lines.

long-line.xml is only 300 KB, but if you query-replace '</' with '^J</' 
(to break up long lines) and then copy its contents 100 times, and save, 
then kill and reopen and pres M->, you should see the same delay that 
I'm talking about, on master.

The conditions seem to be: no long lines, file size > 20MB.

The profiler output looks the same.

> If you are saying that 'recenter' takes too long in some file, and
> therefore delays M-> for too long, it is probably a separate issue, so
> please report that as a separate bug, preferably with the file that
> causes it.

It seems pertinent to me since ultimately the decision to narrow in 
handle_fontified_prop is driven by the idea that font-lock in large 
files ends up being a problem anyway. And here we have a large file 
where this doesn't help.

But I can file it separately, of course.