GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1342 received at 56682 <at> debbugs.gnu.org (full text, mbox):
On 13.08.2022 17:24, Gregory Heytings wrote:
>
>>
>> But they're not. Of course, modes might have problematic rules
>> (font-lock-keywords are turing-complete, after all), but it might be
>> just as easy to fix all the main major modes rather than hobble user
>> experience.
>>
>
> You've made it quite clear that in your opinion incorrect font locking
> hobbles user experience more than multi-second delays between motion or
> search commands.
I did not.
As soon as the file becomes very large, such that font-lock actually
becomes costly even in properly written major modes, we can still do one
of the two things: apply narrowing during font-lock, or fontify only the
beginning of the file.
That's what two alternative values of font-lock-large-files (added on
the branch) aim to do. But what is the good default value, and if it's
not t, what thresholds to use, those questions require more testing and
user feedback.
>> Especially if we limit ourselves to modes that are likely to be used
>> with large files.
>>
>
> That's not the intention, no.
>
>>
>> So please go ahead and experiment, and report on your findings later.
>>
>
> I already did, and told you that these multi-second delays were still
> present in larger JSON files (and therefore also in smaller files with
> slower CPUs).
Delays or "a delay"? Just the first time you scroll to EOB? Or did you
do the whole dance with editing near BOB, then goto EOB, and repeat?
Did you try that with other file formats? What is the size threshold
where the performance becomes uncomfortable?
>> Then the goal failed because we don't disable bidi hpa? It has a much
>> more noticeable effect on editing that font-lock.
>>
>
> That's not correct, no. The BPA algorithm makes C-n and C-p slower at
> the beginning of large files only in a very specific case: when the
> beginning of the buffer contains opening brackets whose matching closing
> bracket is at the end of the buffer.
To be fair, that's pretty much all JSON files. But I can't quickly
recall any other format with that properly, OK.
> And the BPA algorithm does not
> cause multi-second delays.
The ones I saw seemed pretty bad. And they happened on every command
invocation, not only after you edit the buffer on some distant position.
And bidi-inhibit-hpa is the main cause of C-v/M-v stuttering over here.
>>> Which is why fixing js-mode, and adding a json-mode, as you did, is a
>>> "too local" fix. Of course, that doesn't mean what you did is
>>> useless; it only means that it cannot be considered as a general
>>> solution to the problem at hand.
>>
>> That's not what the branch contains.
>>
>
> You're playing with words. The fixes to js-mode and the added json-mode
> are not on the branch because you installed them on master, but what you
> claim the branch demonstrates depends on what you installed on master.
> Or do you claim that what the branch contains makes editing any other
> file (that is, not a .js or a .json file) almost as fast as what is on
> master?
The branch:
1) Allows everyone interested to evaluate the performance of
unrestricted font-lock even in large files (single-line or not) and see
how big on a problem the delays caused by syntax-ppss actually are in
their experience. It's an important question.
2) Figure out the file sizes where syntax-ppss's performance really does
become a problem. That can give us data for better defaults later.
3) Play around with two easy solutions that we discussed previously:
narrowing during font-lock (one of the values for font-lock-large-files
pretty much matches the current behavior on master), or fontifying only
the first X characters (e.g. 1000000) of the buffer, and skipping on the
rest.
4) It should be plain to see that implementing additional approaches
should be easy enough. For instance, a hybrid like "fontify the first 1
MB correctly, and the rest - on best-effort basis". Although the value
'(narrow . 1000000) should provide behavior a very similar behavior
already. Maybe ever a better one: the boundaries are stable. Maybe sure
to try it together with (setq bidi-inhibit-hpa t): the result looks very
fast to me.
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.