GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 26 Jul 2022 12:34:30 +0000
>
> I don't know the difference between "slow" and "hang".  Gerd says it 
> eventually finishes, so it isn't a "hang" at least on his machine. And 
> my build is unoptimized, so what is "slow" for you probably qualifies as 
> "hang" for me.
>

I just tried again, and on my machine with an optimized build C-s </ RET 
takes 220 seconds to finish (and cannot be interrupted).  That's what I 
call "hang".  With 350e97d78e, C-s </ RET takes about 1 second.  That's 
what I call "slow" (without truncate-lines C-s </ RET is instantaneous).

>
> If you disable lazy-highlighting, does the problem go away?
>

Yes, as I said to Gerd, with (setq isearch-lazy-highlight nil) the problem 
goes away (and C-s </ RET is instantaneous).

>
> And if you customize lazy-highlight-interval and 
> lazy-highlight-max-at-a-time to reasonable values, doesn't the "hang" 
> becomes much shorter?
>

With (setq lazy-highlight-interval 5) the problem does not go away.  With 
(setq lazy-highlight-max-at-a-time 10) the problem goes away, C-s </ RET 
takes about 1 second.




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.