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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 9 Aug 2022 19:52:46 +0300
> Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > 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.

Why is that of importance?  More importantly, how is that proposal
related to what I was discussing with Stefan?

> 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).

I already did.  This trime I got impatient more quickly, and killed
the session only after 5 minutes that it was unable to show me
dictionary.json (after disabling the narrowing).

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

Sorry, I cannot afford trying half-baked solutions.  I asked you to
push a feature branch or an optional feature on master precisely so
that I won't need to hack my development branch.  When such a feature
is available, I'll surely test it in a variety of scenarios,

> >> 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.

Well, my many years of using jit-lock-stealth clearly prove otherwise.
By the time I get to revisit the buffers after some break, they are
already fully fontified.

> 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.

Well, I hope someone will actually try to make that happen.

> 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.

That too.