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

[Michael Albinus]

Paul Pogonyshev <pogonyshev@gmail.com> writes:

> Hello,

Hi Paul,

> any news on this?

I've worked last weeks almost full time on this. With limited success.

Combining stat and readlink into one remote command have even slowed
down the machinery. Likely, because it isn't needed always, but it
always consumes more time to compute both on the remote side, and to
read all the results.

Moving the check of the existence of a file to the end, and let the
commands fail in case the file doesn't exist, isn't possible. Often,
Tramp needs to know in advance the size of a given file, for example to
decide whether to encode/decode the file or to invoke scp, or to know
whether the file shall be compressed prior transfer. Checking the file
size is much the same as checking the file existence.

Avoiding the "are you awake" command is still on my todo list, but it
isn't trivial. There is a complex machinery to be invoked in case the
command fails, in order to reestablish the connection in the
background. It still might be possible to change this, but it isn't
trivial.

Bu there are also some results. With commit
9ed5c39aad09571314097be91cb28e7504614421 I've refactored major Tramp
parts in order to have a better chance to apply performance
changes. This includes already some changes to combine several commands
(avoiding superfluous roundtrips) and alike. There's also commit
dfa16cadc18930fad76fa6113750eaa27d367e72 fixing a regression which was
introduced with the former patch.

In my test environment, performance improvement of these changes is not
overwhelming. But I sit in a LAN, with good connections. Perhaps you
give it a try to see, whether your use cases behave better.

I'll continue to work on this, but don't expect wonders.

> Paul

Best regards, Michael.