Re: Filtering out process filters

[Augusto Stoffel]

On Thu,  5 Jun 2025 at 01:09, Daniel Colascione wrote:

> Benchmarks are all useful simplifications.  The only really
> representative benchmark is use, and we're allergic to telemetry.

Well, the only 100% realistic benchmark is use, but we can still have
simplified yet representative ones, right?

The blocking version is representative of a blocking use case, such as
Gnus downloading a message.  I'm just claiming it doesn't seem
sufficiently representative of an asynchronous tool such as Eglot.

> You can construct a scenario in which the relative performance of IO
> strategy gets washed out by other considerations (the performance of
> *everything* in your scenario collapses), but that doesn't make the
> difference stop existing.

Fair enough, as long as we are clear that redisplay influences
subprocess IO quite a lot in practice, in ways that may wash out other
optimizations :-).

> I tried your version in both interactively and in batch mode, on NS.
> Interactively, it didn't finish.  Profiling indicated ~100% of CPU time
> was spent on lock waits in ns_select and, on another thread, logging(!).
>
> In batch mode (I had Emacs join your thread), performance was the same
> as we've been discussing.  Same in -nw.  Something seems wrong with the
> NS event loop, but I think that's orthogonal to this discussion.

There are other ways to make the benchmark non-blocking, such as killing
the subprocess and printing the report directly in the filter or acf in
order to get rid of the "while accept-process-input" loop.

> In any case, 64 MB/sec is terrible. That's, what, half the memory
> bandwidth of an 80486-era machine?  Maybe we should declare threads a
> failed experiment and encourage JS-style structured concurrency instead.

That's another topic entirely, but yes, the "asyncio" stuff would be
nice to have.