GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1935 received at 56682 <at> debbugs.gnu.org (full text, mbox):
On 29/11/2022 22:11, Gregory Heytings wrote:
>>> - with Emacs 28, after C-s eman RET, I see ~20 ms, and after C-s aan
>>> zich RET, I see ~3000 (!) ms
>>
>> Yup, the long delays near EOB are expected, I fixed them in js.el not
>> too long ago (one in font-lock rules, and anothing by creating
>> js-json-mode).
>>
>
> So what? We had in that file 20 ms at BOB and 3000 ms at EOB, which
> means an average of 1500 ms (in that file). Now we have 100 ms at BOB
> and EOB, which means an average of 100 ms (in that file). How can that
> be a regression?
But the improvement near EOB in this scenario down from 1500 ms is not
necessarily from the long-lines feature.
Like Eli pointed out, try (setq long-line-threshold nil).
The result will be that the benchmark will report ~30ms both near BOB
and near EOB. So the long-lines-threshold thingy adds a regression here.
Again, not trying to criticize or anything, but a 100ms is usually
considered as something that brings an operation from appearing
"instantaneous" down to "noticeable delay". Since we're trying to make
editing large files easier and snappier, that seems worth fixing.
Not to mention that the user might have other features enabled that can
add a multiplier on top of this delay -- which is apparently the case in
my personal configuration.
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.