bug#56342: TRAMP (sh) issues way too many commands, thus being very slow over high-ping networks

[Michael Albinus <michael.albinus@gmx.de>]

Paul Pogonyshev <pogonyshev@gmail.com> writes:

Hi Paul,

>> Doing it asynchronously would require a second connection to the remote
>> host. Performance would rather degrade.
>
> Maybe not really asynchronously, just let it return early, not waiting
> for the result? I'm not sure how TRAMP receives responses, but can it
> just keep executing commands sequentially, as now, but give control
> back to the caller in case of commands where the result doesn't really
> matter (cleanup, e.g. deleting a temporary file). Of course, this
> means that if an "important" command is issued right away, it has to
> wait for the response to the previous inessential command. But when
> such an inessential command is the last in a batch, this waiting would
> be effectively merged with Emacs' idling in the normal UI command
> loop, making things more responsive for the user.

Tramps communication with the remote host is like a REPL engine. It
sends shell commands to the remote hosts, reads the result, and waits
for the shell prompt. If it doesn't wait for the final shell prompt, it
is likely that the result or the shell prompt will be seen when reading
the output of the next command. This confuses. So no, I don't see a
chance to implement this kind of "asynchronity".

> Paul

Best regards, Michael.