Subject: bug#79132: 30.1; lots of overlays with box face causes high usage of redisplay_internal

From: Eli Zaretskii <[email-masked]>
Date: Fri, 01 Aug 2025 10:39:17 +0300

> Date: Thu, 31 Jul 2025 16:21:31 +0200
> Cc: [email-masked]
> From: Godefroy Vannoye <[email-masked]>
> 
> Thanks a lot for the quick response.
> 
> Digging around a bit it seems to be almost exactly the same as bug#74691
> (Long errors with flymake-show-diagnostics-at-end-of-line really slows 
> movement).

Possible, but not certain.  You said in your case the profile pointed
to redisplay_internal, not to line-move-visual.

> I had suspicions it would be difficult. On the top of my head I could 
> imagine some caching
> of where the boxes need to be drawn would help, but of course it's 
> easier said than done…

The display engine cannot cache display-related information more than
it already does, because the buffer contents and overlays (and other
relevant variables) could completely change between redisplay cycles.

> Another possibility could be to not draw the boxes except after some 
> idle time.

That should be done already, if the box face is part of font-lock
machinery.  You could try playing with jit-lock-context-time and
jit-lock-defer-time to try to change the defaults which control that.

> I have a curiosity question: what makes box particularly more expensive 
> compared to
> other faces properties like underline or strike-through (for which no 
> slowdown is observed)?

The other properties can be handled on character basis, i.e. consider
for each character separately whether it has or doesn't have the
attribute.  By contrast, the box attribute needs special processing
for the first and the last character in the run of characters that
have the box attribute: those need the vertical border drawn.  This
requires the display engine to look back and forward in the buffer in
order to determine whether the character is the first or the last in
the boxed run, and that takes additional CPU time.