Re: Major modes using `widen' is a good, even essential, programming practice.

[Dmitry Gutov <dgutov@yandex.ru>]

On 09.08.2022 19:12, Eli Zaretskii wrote:

>> I never recommended you to change any of those vars.
> 
> Then I don't really understand what is it that you are arguing about.
> 
> My proposal to Stefan was to make syntax-ppss and friends less of a
> burden _instead_ of the currently implemented "arbitrary restrictions"
> that he doesn't like.  You seemed to have contradicted my proposal by
> saying that the file is already displayed quickly enough, but that
> only happens _with_ those "arbitrary restrictions".

No, it doesn't.

You might recall the patch I suggested recently that doesn't change 
either of those vars but disables narrowing in handle_fontified_prop.

BTW, you can try js-json-mode in the latest master, I have fixed another 
source of slow font-locking there (coming from js-mode).

Just remove the expression that starts with 'if 
(current_buffer->long_line_optimizations_p)' from handle_fontified_prop, 
recompile, and visit dictionary.json.

>>> Not surprisingly, this is precisely how jit-lock is supposed to work,
>>> if only the stuff called through fontification-functions obeyed the
>>> region which it was told to process.
>>
>> If you concerned with the speed of font-lock itself (and not with the
>> speed of syntax-ppss cache maintenance which we've talked about before),
> 
> I'm concerned with both, because font-lock typically calls syntax-ppss
> in many modes.

"Stealth" syntax-ppss, to have any visible impact, is likely to have the 
problem I described: lots of work, the results of which are regularly 
discarded. Meaning, lost of wasting CPU energy.

What might work better instead (and would benefit specifically the 
scenario with a lot of jumping around and editing in different parts of 
a large file) is to try to avoid dumping the whole spss cache when the 
use edits near BOB, and instead record the fact of such edits but later, 
but later try to "revalidate" the cache entries by calling 
parse-partial-sexp on the interval where the edits occurred in the 
meantime, and keep them if the result shows that the edits should have 
no effect on the later values. That's something tree-sitter does, AFAIU, 
but for much complex parse tree.

Anyway, that approach would require some work and subsequent testing, 
and it would improve performance for a particular class of operations. 
It's not a given that the performance issues you see in CC Mode fit that 
profile.

And I hope that somebody could look into improving that 10x difference 
between yours and mine performance of parse-partial-sexp first, so then 
we could see where the remaining bottlenecks are.