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

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/

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

[Robert Pluim]

>>>>> On Wed, 25 May 2022 15:10:55 +0300, Jean Louis <bugs@gnu.support> said:

    Jean> I have read in Emacs News by Sacha Chua, about this Eshell speed up:
    Jean> From 70 Seconds To 3 Seconds
    Jean> https://tdodge.consulting/blog/eshell/background-output-thread

    Jean> and the fork of Emacs is here:

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

    Jean> 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.

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

Maybe. What's the copyright status of those changes?

Thanks

Robert
-- 

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

[Tyler Dodge]

Hi Robert,

Thanks for reaching out. I’d love to sign over the copyright for this. Please let me know what you all need from my end to facilitate that.

Tyler Dodge

> On May 25, 2022, at 9:23 AM, Robert Pluim <rpluim@gmail.com> wrote:
> 
> 
>> 
>>>>>> On Wed, 25 May 2022 15:10:55 +0300, Jean Louis <bugs@gnu.support> said:
> 
>    Jean> I have read in Emacs News by Sacha Chua, about this Eshell speed up:
>    Jean> From 70 Seconds To 3 Seconds
>    Jean> https://tdodge.consulting/blog/eshell/background-output-thread
> 
>    Jean> and the fork of Emacs is here:
> 
>    Jean> GitHub - tyler-dodge/emacs: Fork of emacs mirror Emacs. Has a
>    Jean> background thread optimization for getting past the 1024 byte
>    Jean> bottleneck on MacOS
>    Jean> https://github.com/tyler-dodge/emacs
> 
>    Jean> 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.
> 
>    Jean> Maybe developers and author may find it useful to implement author's
>    Jean> feature in the main stream Emacs?
> 
> Maybe. What's the copyright status of those changes?
> 
> Thanks
> 
> Robert
> -- 

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

[Eli Zaretskii]

> From: Tyler Dodge <tyler@tdodge.consulting>
> Date: Wed, 25 May 2022 13:18:52 -0700
> Cc: Jean Louis <bugs@gnu.support>, Emacs Developers <emacs-devel@gnu.org>
> 
> Hi Robert,
> 
> Thanks for reaching out. I’d love to sign over the copyright for this. Please let me know what you all need from my end to facilitate that.

Thanks, form sent off-list.

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

[Robert Pluim]

>>>>> On Wed, 25 May 2022 13:18:52 -0700, Tyler Dodge <tyler@tdodge.consulting> said:

    Tyler> Hi Robert,
    Tyler> Thanks for reaching out. I’d love to sign over the copyright for
    Tyler> this. Please let me know what you all need from my end to facilitate
    Tyler> that.

I saw Eli sent the form. I haven't looked at the changes, but if
youʼre willing to work on getting them integrated into Emacs that
would be great, otherwise Someone™ Else™ would have to do it.

Basically, if the changes have commit messages that follow the Emacs
style, and they have documentation somewhere, that would be a good
start.

Robert
--