bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode

[Alan Mackenzie]

Hello, Eli.

On Tue, Dec 07, 2021 at 14:58:08 +0200, Eli Zaretskii wrote:
> > Date: Mon, 6 Dec 2021 20:53:15 +0000
> > Cc: bug-gnu-emacs@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > This is no longer the case in Emacs 29.  There, if you visit a C file,
> > > you will see a flurry of stderr messages about constant redisplay
> > > cycles being forced.  It seems like the culprit is the function
> > > 'c-type-finder-timer-func', which is run from a timer at 10 Hz (!),

> > That is customisable with c-type-finder-repeat-time.  The idea is to
> > have this as often as possible so that the backgroud scanning is
> > complete as soon as possible.  (See my next paragraph.)

> Yes, but why would I need to do one more chore to get me a "silent"
> redisplay?  And why does this timer cause such a serious work to the
> display engine?

I think there's still a bug in the mechanism.  This mechanism was the
outcome of a long thread in the list a few months ago, complaining about
the perceived randomness of CC Mode's font locking.  It scans all CC
Mode buffers at startup, and each buffer which gets visited, to detect
"found types".  For each occurrence anywhere in the buffer of a newly
"found type", the fontified text property gets set to nil.  Further, if
this occurrence is in a currently displayed window, a redisplay gets
triggered.

In a (hopefully fixed) bug, there occurred constant redisplay, because
the newly found types weren't getting properly added to
c-found-type-list.  The same thing might still be happening in a
different way.

> > If this processing continues beyond the time to scan all CC Mode
> > buffers, then there is a bug.  A megabyte long file (xdisp.c) scans in
> > aroung 18 seconds on my machine.

> 18 seconds is almost an eternity for my frequent use cases of firing
> up Emacs to debug some display problem.  And it's much more than 18
> sec here: I measured 4 minutes and 21 sec, with 1:54 CPU time.  My
> build is unoptimized, but still, a factor of 13 wrt your timing is too
> much to be explained by that alone.

Is that with xdisp.c the only CC Mode buffer?  When my desktop had
around 700 buffers, many of them CC Mode, the total background
processing was of the order of 10 minutes (optimised build).

That 4 minutes 21 seconds - does the thrashing of the redisplay stop
after this amount of uptime?

As a matter of interest, is Emacs responsive to key strokes when this is
happening?

> > It can be disabled by setting (or customising) c-type-finder-time-slot
> > to nil.  As I say, the activity should cease after a few seconds, or a
> > few minutes with a well filled desktop.

> Once again, it takes much more here.  And my main question was left
> unanswered: what does this timer function do to cause such thorough
> redisplay cycles, when I know that nothing was changed in the buffer?
> can you please describe what this function does that could have such
> an effect?

What changes in the buffer is the detection of "foo", "bar", ... as
found types.  These get marked throughout the buffer with the fontified
text property set to nil, and if an occurrence is in a displayed window,
that triggers an immediate redisplay to refontify that visible
occurrence of the found type.  I think this repeated redisplay is
happening too often.

-- 
Alan Mackenzie (Nuremberg, Germany).