bug#44007: 26.3; Strange shell mode performance

[Herman]

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Herman, Géza <geza.herman@gmail.com>
> >
> > I thought that the fd is nonblocking here.
>
> That doesn't matter here.  The problem is not with blocking in 
> 'read',
> the problem is with calling one 'read' after another without 
> letting
> Emacs process the foreground input events.
I see.  But this loop only loops until either there are no more 
bytes, or it reaches 'nbytes'. Unless the OS splits the available 
output into very tiny bits, this shouldn't be a problem.  But that 
would be a bad behavior from the OS part.  And even if the data is 
splitted into tiny bits, the only extra time we pay for is the 
overhead of the extra read() calls.  Maybe for some OS's this can 
be significant, I'm not sure.  For my case, data is only splitted 
into two pieces (4095 + 1), I don't think this causes any serious 
problem, even theoretically.

But anyways. Before I added this hacky solution to Emacs, I had 
been an Emacs user for at least 8 years, so I knew how Emacs 
behaved in certain circumstances. Then I added this hack. Since 
then I didn't notice any bad behavior or difference, except that 
I/O become much faster for me. So we have at least one data point 
that this kind of approach works and doesn't cause any trouble.

I know that this is a problem for some people, because when I 
searched for the cause of this issue, I found multiple reports of 
shell being slow in Emacs. The last one happened just several days 
ago on reddit: 
https://www.reddit.com/r/emacs/comments/17nl7cw/comment/k7tmgz0/?utm_source=share&utm_medium=web2x&context=3
(this reddit comment made me to spend some time investigating the 
issue again), explaining the same exact issue I'm having.

But of course, it is possible that this read() loop will cause 
trouble for someone. But we're not able to tell this until others 
try this out.