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

Previous Next

Package: emacs;

Reported by: Paul Pogonyshev <pogonyshev <at> gmail.com>

Date: Fri, 1 Jul 2022 17:15:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 56342 <at> debbugs.gnu.org
Subject: bug#56342: TRAMP (sh) issues way too many commands, thus being very slow over high-ping networks
Date: Sun, 03 Jul 2022 14:16:24 +0200
Paul Pogonyshev <pogonyshev <at> gmail.com> writes:

Hi Paul,

> Some more thoughts. Why does it even need `echo are you awake'? It's a
> network connection, it can still fail even if it worked fine 1 ms
> before when you checked. So, why not just let the first command fail
> if the connection is dead and restart the connection if it fails in
> such a way as to suspect that it is dead (i.e. no output)? Maybe limit
> this to read commands.

This is a sanity check. It avoids to hang in a blocked connection,
because this special command is surrounded by a timeout of 10 sec. Other
commands w/o this protection could hang forever. See also the comment in
tramp-maybe-open-connection.

> A way to let higher-level code avoid certain `file-exists-p' calls:
> add a dynamic variable that tells TRAMP to skip certain commands if
> the result is not available from a cache. Something similar to
> `process-file-side-effects'. Calling code could then do sth. like
> this:
>
>     (when (let ((tramp-may-skip-if-not-cached `((file-exists-p unknown
> ,file))))
>             (file-exists-p file))  ; TRAMP will return t or nil if it
> knows or 'unknown if not cached; for local files there is no effect
>       ...)
>
> Suggested semantics: list of (FUNCTION INSTANT-RESULT-IF-NOT-CACHED
> ARGUMENT...). Any element of the list with unknown function name etc.
> would be simply ignored.
>
> Code that doesn't let-bind this variable will behave as before. Code
> that cares can be optimized.

If a caller can live w/o a valid result of file-exists-p, it shouldn't
call it. Everything else is too sophisticated and good for trouble, I believe.

In general, packages shall not care what's the implementation of a given
function like file-exists-p. If they care, they could still use
file-remote-p in order to distinguish.

> Paul

Best regards, Michael.




This bug report was last modified 1 year and 27 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.