limitation in how emacs processes subprocess output, maybe belongs to mainstream

[Jean Louis]

I have read in Emacs News by Sacha Chua, about this Eshell speed up:

>From 70 Seconds To 3 Seconds
https://tdodge.consulting/blog/eshell/background-output-thread

and the fork of Emacs is here:

GitHub - tyler-dodge/emacs: Fork of emacs mirror Emacs. Has a background thread 
optimization for getting past the 1024 byte bottleneck on MacOS
https://github.com/tyler-dodge/emacs

Where author writes:

> In a change that I made to my fork of emacs, I added a background
> thread that continuously handles buffering subprocess output. This
> has the benefit of ensuring that the subprocess output is consumed
> as soon as it is available in STDOUT, which minimizes the amount of
> time that the subprocess blocks waiting for emacs to consume its
> output. This also makes it so that the strings passed to the
> subprocess filter can be larger than 1024 bytes because multiple
> reads can happen in the time between event loop evaluations.

Maybe developers and author may find it useful to implement author's
feature in the main stream Emacs?



Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/