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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 10 Dec 2021 22:52:40 +0000
> Cc: 52298@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > > I think that modify_text_properties is calling modiff_incr even when
> > > inhibit_modification_hooks is non-nil.  I tried putting an `if' around
> > > that bit of the code, without any great success.
> 
> > AFAIK, with-silent-modifications is supposed to prevent BUF_MODIFF
> > from increasing.
> 
> I don't think it does in the modify_text_properties case.

Maybe I'm misremembering.

But let me ask you why those 2 text properties are involved in this
case, and what do they signify?  Could we perhaps refrain from putting
them on buffer text when those functions are called from the timer?

And why does that timer have to tick so frequently?

> > Are you sure you see that?  And what kind of 'if' did you try to put
> > and where?
> 
> In modify_text_properties, around the modiff_incr bit:
> 
> diff --git a/src/textprop.c b/src/textprop.c
> index d7d6a66923..d91b8624ef 100644
> --- a/src/textprop.c
> +++ b/src/textprop.c
> @@ -85,10 +85,13 @@ modify_text_properties (Lisp_Object buffer,
> Lisp_Object start, Lisp_Object end)
> 
>    prepare_to_modify_buffer_1 (b, e, NULL);
> 
> -  BUF_COMPUTE_UNCHANGED (buf, b - 1, e);
> -  if (MODIFF <= SAVE_MODIFF)
> -    record_first_change ();
> -  modiff_incr (&MODIFF);
> +  if (!inhibit_modification_hooks)
> +    {
> +      BUF_COMPUTE_UNCHANGED (buf, b - 1, e);
> +      if (MODIFF <= SAVE_MODIFF)
> +       record_first_change ();
> +      modiff_incr (&MODIFF);
> +    }

And modiff_incr is still being called?  How's that possible, unless
you don't use with-silent-modifications when you put those 2
properties?  Or maybe modiff_incr is called from some other place as
well?

> > Once again, the problem is not that redisplay is invoked, the problem
> > is that it doesn't exit almost immediately, after detecting that
> > nothing's changed.
> 
> I'm again not entirely convinced we have a problem.  When trace-redisplay
> is enabled on my machine, and xdisp.c visited, Emacs uses between 20% and
> 25% of one CPU core for a little under 2 minutes (a 4½ year old Ryzen).
> After this it is down to 0.3%.  All the time it is outputting
> trace-redisplay messages, two I think for each timer iteration.

Your Emacs is running TTY frames only.  On my system, during that
stage, Emacs displaying on a GUI frame consumes 50% of 1 execution
unit doing this stuff.  And 20% to 25% for 2 minutes is not
negligible, either.  So yes, we do have a problem.  And we always will
have a problem when redisplay goes that far in its processing when
there's nothing to do, actually, and we invoke it so frequently.  So
please, let's try to solve this, or at least understand what's going
on well enough to make a decision.

> I'm a bit surprised at the moment it's taking so long to do the initial
> found-type scanning, but it's not all that bad.

Well, that surprise of yours is another indication that we don't have
a good understanding of what's going on here.  Can we please try to
understand that fully?