bug#44007: 26.3; Strange shell mode performance

[Eli Zaretskii <eliz@gnu.org>]

> From: Herman, Géza <geza.herman@gmail.com>
> Cc: Herman Géza <geza.herman@gmail.com>,
>  44007@debbugs.gnu.org
> Date: Mon, 06 Nov 2023 13:28:15 +0100
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure what exactly are we trying to do here.  AFAIU, at 
> > least 2
> > variables were discovered that can speed up this example, so 
> > what else
> > has to be done?  Is there any bug here, and if so, what is the 
> > bug?
> 
> The bug is that if echo is enabled, emacs 'shell' gives a much 
> worse performance.

I'm trying to understand why would we consider that a bug.  There will
always be ways to make Lisp programs run slower or faster by tweaking
some variables, and the defaults are not always capable of providing
the best performance in every possible situation.

> And it has no apparent reason why it should be the case.

You (or anyone else) should of course feel free to investigate and try
to find out what are the specific reasons which make Emacs slower in
some cases and faster in others.  But that doesn't necessarily
constitutes a bug, IMO.

> I'd like to also mention that my hacky solution not just fixes the 
> problem, but also improves shell's performance, even with the 
> mentioned variables set.  As far as I know POSIX programming, 
> read() should always be called in a loop, if one wants to read N 
> bytes (even in the successful case).  Emacs doesn't have this in 
> emacs_intr_read, that causes the problem.

We've arrived at the current code after a lot of iterations, and it
has to handle many different uses.  It doesn't surprise me a bit that
you can find a change which speeds up Emacs in some particular case,
but what about all the other cases?

How about if you run with this change for a few weeks or so, and see
if it doesn't cause problems elsewhere?  maybe also others will try
using it in their use patterns and report back.  Then we will at least
have some data regarding the effects of the change you propose.

Of course, if someone comes with a less hacky proposal, it would be
even better.

Also, please be sure to try Emacs 30, as I believe some changes were
done there recently.

Thanks.