|
From: | Dmitry Gutov |
Subject: | Re: Major modes using `widen' is a good, even essential, programming practice. |
Date: | Tue, 9 Aug 2022 19:52:46 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |