Re: Filtering out process filters

[Daniel Colascione]

Augusto Stoffel <arstoffel@gmail.com> writes:

> On Wed,  4 Jun 2025 at 17:01, Daniel Colascione wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Btw, I still don't have a clear idea why the ACF method is so much
>>> faster, since it basically does the same stuff.
>>
>> The ACF method, in the unibyte case (which is what you want for JSON and
>> terminal alike) boils down to memcpy() in process.c from the `chars`
>> buffer to the literal buffer contents --- followed by a cheap Lisp call
>> touching cache-hot conses (the ACF list).
>
> That probably makes it a bit faster, but I'm skeptical it can be so much
> faster.
>
> Did you see my previous message, where I changed the benchmark to not
> block the UI?  Benchmarks that do
>
>   (while (accept-process-output ...))
>
> on the main thread are not representative of the typical use cases.

Benchmarks are all useful simplifications.  The only really
representative benchmark is use, and we're allergic to telemetry.
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.

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.

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.