Re: Filtering out process filters

[Daniel Colascione]

On June 3, 2025 9:06:29 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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.


Do we want to run : eval modeline functions (and pre-redisplay-functions for 
that matter) when a buffer that isn't visible changes? ISTM such a redisplay 
shouldn't "count"