bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-t


From: Alan Mackenzie
Subject: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode
Date: Mon, 6 Dec 2021 20:53:15 +0000

Hello, Eli.

On Sun, Dec 05, 2021 at 09:46:29 +0200, Eli Zaretskii wrote:
> It used to be the case that starting "emacs -Q" and disabling
> blink-cursor-mode and global-eldoc-mode was enough to get me Emacs
> that doesn't perform redisplay unless required.  To see this, do the
> following with any Emacs up to and including Emacs 28:

>   emacs -Q
>   M-x blink-cursor-mode RET
>   M-x global-eldoc-mode RET
>   M-x trace-redisplay RET

> (The last command is only available if you configured with
> "--enable-checking=yes,glyphs".)  This would produce a few lines of
> output on stderr, and then stop until you do something in Emacs, like
> move the cursor with an arrow key.

> 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.)

> and which for some reason forces Emacs to perform a redisplay cycle
> with that frequency.  The trace itself, viz.:

>   redisplay_internal 0
>   071a03c8 (xdisp.c): try_window_id 2
>   redisplay_preserve_echo_area (8)

> means that the processing induced by that timer function is far from
> being trivial, which means something that this function does causes
> Emacs to think some real change might have happened in the buffer.

The idea is that this processing only happens a short while after
loading a C file, the time being taken up by checking for the
fontification of "found types", that is identifiers identified as types
in the rest of the buffer somewhere.

> Not even "emacs -Q -D" is enough to get rid of this
> 'c-type-finder-timer-func' timer in CC Mode buffers.

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.

> Is it possible to prevent this frequent timer from firing when no
> changes have been done to the buffer?  And in any case, please try to
> include some logic in that function to avoid whatever it does now to
> force such frequent non-trivial redisplay cycles.  If nothing else,
> laptop users will hate us if we release Emacs with this behavior.

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.

There have been a couple of bugs in this area recently, one fixed
(stupidly) on the release branch (where there wasn't a problem).  The
other one was fixed in master.  By recently, I mean last Wednesday and
Saturday 2021-11-13.

But even given the above, I've a sneaking suspicion there's still a bug
here, which I'll have a look for (but not tonight).

> In GNU Emacs 29.0.50 (build 297, i686-pc-mingw32)
>  of 2021-12-04 built on HOME-C4E4A596F7
> Repository revision: f247fa5d5ce7cb34f23c979c17b14c5713eb5490
> Repository branch: master
> Windowing system distributor 'Microsoft Corp.', version 5.1.2600
> System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

> Configured using:
>  'configure -C --prefix=/d/usr --with-wide-int
>  --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]