|
From: | Dmitry Gutov |
Subject: | bug#56682: locked narrowing |
Date: | Tue, 29 Nov 2022 22:36:05 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 29/11/2022 21:51, Eli Zaretskii wrote:
Date: Tue, 29 Nov 2022 21:29:59 +0200 Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca From: Dmitry Gutov <dgutov@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".
[Prev in Thread] | Current Thread | [Next in Thread] |