GNU bug report logs - #57207
29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57207 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling)
Date: Tue, 16 Aug 2022 12:17:10 +0000

>
> As I said earlier, I've changed my mind about this after I wrote the 
> above.
>

I did see that, yes.

>
> We update UNCHANGED_MODIFIED in mark_window_display_accurate_1, so if 
> the window completes its redisplay cycle "normally", whatever jit-lock 
> does shouldn't matter for the next redisplay cycle, because 
> UNCHANGED_MODIFIED will be updated from MODIFF.
>

Hmmm...  The fact is that using CHARS_MODIFF avoids rescanning the buffer 
when "too many" text properties are changed.  With xdisp.c, the long lines 
detection code is not called anymore when scrolling through the (initially 
unfontified) buffer.  The original bug description (additional delays 
between redisplay cycles in a large buffer) is probably caused by 
needlessly executing that long lines detection code, at least that's 
consistent with my earlier experiments.

>
> Maybe Org does something that frequently causes a window's redisplay 
> cycle to end prematurely, in which case the code that looks for long 
> lines could be called too frequently.  But in that case, your proposed 
> change will have the same problem, I think?
>

That's possible indeed, let's see what Ihor tells us.

>
> What I don't understand is why enlarging the value of the threshold 
> causes Emacs to "hang".  If it really is some kind of infloop, I cannot 
> understand how issues like outdated UNCHANGED_MODIFIED could cause that 
> only for some value of the threshold, but not for a smaller value.  I 
> thought perhaps there are lines longer than 10000 characters, but none 
> beyond 100000, but this turns out to be false, so with both values of 
> the threshold that loop in redisplay_window should have scanned the 
> entire buffer top to bottom in both cases...
>
> So I suspect something else is at work here.
>

Yes, I suspect that this is another bug, separate from the original bug 
Ihor described.  It might be a bug in find_newline1, in the backtrace he 
sent, find_newline1 returns 10568710 and later 9679581.  It's not clear 
however if that's in the same loop (he asked gdb to "continue" between the 
two).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.