Re: Filtering out process filters

[Eli Zaretskii]

> Date: Tue, 03 Jun 2025 06:22:37 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: arstoffel@gmail.com, emacs-devel@gnu.org
> 
> >Emacs calls redisplay_internal each time it becomes idle after being
> >non-idle, so the sheer number of calls just tells us the rate at which
> >the Emacs main loop is looping, nothing more.  You can produce a
> >similar effect by adding a high-frequency do-nothing timer, for
> >example.  (Not that I'm saying that using after-change-functions adds
> >such a high-frequency timer.  It's just an example of how the number
> >of calls to redisplay_internal can easily become higher.)
> >
> >To raise concern about nontrivial redisplays, one has to show some
> >evidence that each call to redisplay_internal does something more
> >complex than walking the window tree and determining that nothing
> >needs to be done.
> 
> Sure. I still need to take a look myself. I'd just expect this process of 
> determining that nothing needs doing to be a drop in the bucket compared to 
> the cost of the select-and-read loop, so reports of spending enough time in 
> redisplay to shift the benchmark results are surprising. That suggests that 
> either redisplay is doing more than determining that it needs to do nothing 
> or that walking the window tree and checking flags is a lot more expensive 
> for some reason than I expect.

Not sure about the benchmark, but the profile seems to tell that most
of the functions shown there are called via :eval from the mode line.
AFAIR, if the mode line needs to be updated, several redisplay
optimizations are disabled.