Re: Filtering out process filters

[Daniel Colascione]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 03 Jun 2025 09:54:29 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: arstoffel@gmail.com, emacs-devel@gnu.org
>> 
>> >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?
>
> We don't, at least not in general.  However:
>
>   . It is very non-trivial to determine accurately and reliably
>     whether a mode line needs redrawing, especially if it uses :eval
>     (which basically can do anything and everything).  For a trivial
>     example, imagine that :eval's result is somehow affected by
>     buffers that are not shown on display, like sum of sizes of all
>     buffers or something.  In such situations we typically "err on the
>     safe side".
>
>   . The "update modelines" flag is itself a blunt instrument: it
>     disables various shortcuts that _might_ be affected, even though a
>     particular reason for setting the flag does not necessarily
>     contradict some of those shortcuts.
>
> Again, this is pure theory: whether these factors indeed affect the
> specific cases in point is anyone's guess.  If Augusto describes his
> mode-line related customizations, I could walk through the display
> code and see if any of the above is in fact relevant.  Alternatively,
> I could tell where those shortcuts are, and then someone else could
> see if they are taken or not given his/her customizations.
>
> Eventually, if some important enough use cases get slowed down due to
> redisplay optimizations that aren't smart enough, we could add flags
> that allow us to determine whether some changes to global state don't
> require thorough redisplay, and add new shortcuts based on such flags.
> I'm quite sure that the aspects of redisplay (if indeed it's redisplay
> that slows down the scenarios we are discussing) relevant to this
> discussion were never seriously considered when redisplay
> optimizations were designed and implemented.

Interesting. I ran my benchmark on an interactive session.

Default gc size for all of these.

Baseline (batch):

buffer+acf: 5037 MB/s
term: 314 MB/s
jsonrpc: 577 MB/s

NS -nw:

buffer+acf: 5046 MB/s
term: 108 MB/s
jsonrpc: 208 MB/s

NS:

buffer+acf: 1353 MB/s
term: 93 MB/s
jsonrpc: 149 MB/s

The NS slowness persists if I set mode-line-format (both locally and
globally) to "".

At least for me, the rank order of buffer+acf
vs. filters persists, but GUI Emacs is just much slower for some reason.
ns_select does a bunch of random things I haven't totally grokked, but
it shouldn't be _that_ bad.