Re: Filtering out process filters

[Daniel Colascione]

On June 3, 2025 4:35:22 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 02 Jun 2025 17:35:10 -0400
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: emacs-devel@gnu.org
>> 
>> 
>> 
>> On June 2, 2025 4:47:54 PM EDT, Augusto Stoffel <arstoffel@gmail.com> wrote:
>> >On Mon,  2 Jun 2025 at 16:02, Daniel Colascione wrote:
>> >
>> >> The process buffer is the one displayed?
>> >
>> >No.
>> >
>> >> I should clarify that the model I have in mind is that we have
>> >> processes write to a hidden internal buffer, parse that, then update
>> >> the visible buffer with the result --- if we have a visible buffer at
>> >> all. jsonrpc already has an internal buffer; term would need to make
>> >> one to store in-flight unprocessed text. acf probably isn't a good
>> >> idea if you want the process to write straight to a user buffer.
>> >
>> >Sure, I get that.
>> >
>> >In my test a bunch of overlays (misspelling markings) are created in the
>> >buffer being displayed as the process output comes in.  I've now
>> >repeated the test while keeping the target buffer buried, so neither the
>> >process buffer nor the buffer being modified from the filter/acf is
>> >visible.
>> >
>> >This change makes the filter version substantially faster and the acf
>> >version somewhat faster, but in any case the profile is still dominated
>> >by `redisplay_internal'.  I've attached the profiler reports.  (By the
>> >way, binding inhibit-redisplay to t in the filter or acf doesn't seem to
>> >have much of an effect.)
>> 
>> Huh. The subject of this thread aside, it's odd that modifications to a 
>> buffer that isn't even visible would cause nontrivial redisplays. Is this a 
>> stock configuration? 
>
>Where's the evidence that these redisplays were "nontrivial"?  AFAICT,
>the only fact we have is that the number of calls to
>redisplay_internal was much larger, but we have no information to say
>that each call did some nontrivial job.  Or did I miss something?
>
>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.