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

From: Dmitry Gutov <[email-masked]>
Date: Mon, 15 Aug 2022 13:06:14 +0300

On 15.08.2022 05:32, Eli Zaretskii wrote:
>> Date: Mon, 15 Aug 2022 01:07:08 +0300
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>> On 14.08.2022 21:27, Eli Zaretskii wrote:
>>>> Date: Sun, 14 Aug 2022 21:14:00 +0300
>>>> Cc: [email-masked], [email-masked], [email-masked]
>>>> From: Dmitry Gutov <[email-masked]>
>>>>
>>>> The implementation of the idea that Gregory mentioned (font locking
>>>> reasonably accurate even when it doesn't have access to the whole
>>>> buffer) will have to be done in Lisp anyway. So that's where the
>>>> narrowing should be applied too.
>>>
>>> I don't see how it follows.  If we decide (and I don't say we did, but
>>> if we do) that fontification-functions must run narrowed, then they
>>> will run narrowed, and the best place to do that is in the caller.
>>
>> Only if we somehow decided that it makes sense to always use the same
>> narrowing bounds. But as experiment shows, font-lock can use 100x larger
>> narrowing, and still perform well.
> 
> So what?  The proponents of the widening claim that they need to go to
> BOB, and no "arbitrary" narrowing smaller than that will suffice.

I'm trying to support several approaches, including narrowing.

> And btw, I have very different impression of what happens with 100x
> larger narrowing on my machine and with unoptimized builds.

Given what we've seen about your parse-partial-sexp's performance (10x 
slower than mine), I would hope for someone to figure out why it's so 
slow in your unoptimized build. But if it doesn't happen, you would 
probably use a different threshold/narrowing radius (through customization).

It would make sense for our defaults not to be tailored to this very 
particular development rig.

>> Further, the thing which is going to call the language-specific
>> safe-position-finding logic is likely to want to update the bounds of
>> the narrowing (to then call syntax-ppss within those bounds, where START
>> is a "safe" position).
>>
>> So yeah, the font-lock related widen/narrowing logic should indeed live
>> in one place. And until now it has resided in font-lock-fontify-region.
> 
> Since when is font-lock-fontify-region specific to a language?  It is
> as general as xdisp.c.

syntax-propertize is general, and yet it invokes language-specific rules 
(through syntax-propertize-function).