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

From: Dmitry Gutov <[email-masked]>
Date: Tue, 16 Aug 2022 17:00:18 +0300

On 16.08.2022 05:33, Eli Zaretskii wrote:
>> Date: Mon, 15 Aug 2022 22:51:16 +0300
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>> On 15.08.2022 19:58, Eli Zaretskii wrote:
>>>> Date: Mon, 15 Aug 2022 19:44:07 +0300
>>>> Cc: [email-masked], [email-masked], [email-masked]
>>>> From: Dmitry Gutov <[email-masked]>
>>>>
>>>>>> 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.