bug#44007: 26.3; Strange shell mode performance

[Herman]

It's already fast on your machine, so that's why pressing RET doesn't 
make a difference.

I tried this on a mac with Emacs 27, and it's easily reproduceable 
(easier than on linux). It seems that on mac, the exact timing of the 
extra RET doesn't matter. Even if it's halfway printing the numbers, 
pressing RET speeds up the remaining part. On linux, I have to press RET 
immediately after executing the command, otherwise it doesn't become faster.

But I've found something right now: this issue is dependent on the 
shell. With zsh, this happens. With bash, it doesn't. Weird. So it seems 
that zsh sets something which makes this issue to appear. Nevertheless, 
I think emacs_intr_read() is not ideal, it should handle the case if 
multiple read() calls needed to gather all the available data (I've been 
using emacs with my hacky patch for more than a year, I didn't notice 
any problems with it).

On 2022-01-29 15:38, Lars Ingebrigtsen wrote:
> "Herman, Géza" <geza.herman@gmail.com> writes:
>
> > How much time does "seq 100000" take for you? Does it use 100% cpu?
> emacs -Q
> M-x shell
> seq 100000
>
> takes very little time for me -- perhaps 0.2s?
>
> If I add a zero, it takes about five seconds, but hitting RET in the
> middle doesn't affect the speed.
>
> > Maybe the OS matters here (how the read() syscall behaves): I'm on
> > debian linux (sid).
> I'm on Debian/bookworm...