GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
On 02.08.2022 05:31, Eli Zaretskii wrote:
>> Just like we do in such cases where an Emacs feature is not optimized
>> enough for a given use case: wait for the user to realize the situation
>> can and should be improved, and file a bug report/feature request.
> The intent of this activity is to make Emacs reasonably performant and
> responsive in the relevant use cases without asking them to wait for
> something that likely won't happen.
>
> IOW, in this case the Emacs developers, due to long-standing bug
> reports about this situation, recognized that it_can_ be improved,
> albeit in slightly unorthodox ways, and have taken the measures to
> optimize Emacs for the users.
It would be a shame to have the better-behaving (faster) major modes
exhibit worse behavior that they could have because of the approach we
choose to solve the long-lines problem.
Regarding the long-standing bug reports, we did solve a bunch of issues
already. One major one, IIUC, was redisplay of already fontified text on
long lines. Another piece of the puzzle was added by Stefan in
15b2138719b340.
So perhaps we should re-evaluate the testing scenario to see where the
current bottlenecks are. If we current main issue is the 55s spent in
syntax-ppss, a more constructive approach would be to look into
optimizing parse-partial-sexp. Or even give up on certain scenarios,
admitting that waiting 55s once to visit the end of a 1 GB buffer is not
so bad (and that could part could also be sped up by setting
syntax-propertize-function to nil and using a very simple syntax table,
for instance).
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.