GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
View this message in rfc822 format
On 29/11/2022 21:51, Eli Zaretskii wrote:
>> Date: Tue, 29 Nov 2022 21:29:59 +0200
>> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>>> That's the regression.
>>> The faster ones use a different major-mode, btw.
>>
>> The old (faster) revision uses js-mode, the new one -- the optimized
>> js-json-mode. I'm sure I could have made a mistake doing that
>> optimization, but the behavior doesn't indicate that: the delays are
>> higher near BOB and seem absent near EOB (in master/emacs-29), and they
>> don't show up in the profiler in separate leaf nodes (the previous ones
>> -- which I worked on optimizing -- did).
>
> I didn't say the new mode was the culprit (you could have assumed I tried
> the old mode as soon as I discovered this change since July). I just
> mentioned this for completeness, so we are aware what we are comparing.
For completeness we could also mention that js-mode also had one
significant change in font-lock rules (also an optimization) which is
not as easily transplantable.
> Anyway, do you see any effect if you set long-line-threshold to nil? Here
> it makes the redisplay after insertion instantaneous (and this is an
> unoptimized build, where without setting that variable to nil each insertion
> in dictionary-pp.json takes about half a second).
Yep, that helps.
So the delay is due to it looking for long lines in the buffer, I guess?
Curious why it doesn't happen when near EOB. The benchmark reports a
delay once, but if you run it multiple times, the timing go down to
"instant".
This bug report was last modified 2 years and 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.