|
From: | Herman |
Subject: | bug#44007: 26.3; Strange shell mode performance |
Date: | Sat, 29 Jan 2022 17:10:48 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 |
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...
[Prev in Thread] | Current Thread | [Next in Thread] |