[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: optimize tramp for for many start-file-process'es in parallel

From: Michael Albinus
Subject: Re: optimize tramp for for many start-file-process'es in parallel
Date: Sat, 10 Apr 2021 16:05:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Hendrik Tews <> writes:

> Hi,

Hi Hendrik,

> I am maintaining an Emacs library (coq-par-compile in Proof
> General, details below) that manages a number of parallel running
> background jobs, started via `start-file-process'. To decide,
> which jobs need to be started, the library also uses
> `file-attributes', `file-truename' and maybe other
> remote-file-aware functions. When I use the library with a remote
> file, even over /ssh:localhost:, it gets totally slow. For local
> files Emacs stays responsive, while this library is running. For
> remote files Emacs is more or less locked up.
> I am not a Tramp expert and I haven't spend much time
> investigating, but from what I found, the problem might be that
> Tramp opens a new ssh channel (using ControlMaster, but still
> new) for each asynchronous (`start-file-process') connection.

Yes. Otherwise, it wouldn't be possible to run the processes asynchronously.

> I also see several repeating blocks of
>     00:03:14.329296 tramp-process-one-action (5) # Looking for regexp 
> "\(\(Are you sure you want to continue connecting 
> (yes/no\(?:\(?:/\[fingerprint]\)?)\?\)\)\s-*\)\'" from remote shell


> which seem to be responsible for the delay of 0.03 sec between
>     00:07:26.744746 tramp-process-actions (3) # Waiting for prompts from 
> remote shell...
> and
>     00:07:26.774526 tramp-process-actions (3) # Waiting for prompts from 
> remote shell...done

Likely, yes. This is the handshake for every new remote process, looking
for a password, for other questions during login, and alike.

> I would be very grateful for any hints about how to increase the
> performance of my library for remote files over Tramp.

With Tramp 2.5, so called "direct asynchronous processes" have been
introduced. Instead of calling "ssh -l user -o ControlMasterOptions
host" and then looking, whether there is some interactive ping-pong with
the new remote shell, Tramp calls directly "ssh -l user -o
ControlMasterOptions host <command>". This is much faster. There are
some drawbacks, most moteable a missing possibility to provide a
password. Quoting the Tramp manual:

--8<---------------cut here---------------start------------->8---
   Furthermore, this approach has the following limitations:

   • It works only for connection methods defined in ‘tramp-sh.el’ and

   • It does not support interactive user authentication.  With
     ‘ssh’-based methods, this can be avoided by using a password
     agent like ‘ssh-agent’, using public key authentication, or using
     ‘ControlMaster’ options.

   • It cannot be applied for ‘ssh’-based methods, which use the
     ‘RemoteCommand’ option.

   • It cannot be killed via ‘interrupt-process’.

   • It does not report the remote terminal name via

   • It does not set process property ‘remote-pid’.

   • It does not use ‘tramp-remote-path’.
--8<---------------cut here---------------end--------------->8---

Anyway, you might try it. Install recent Tramp from GNU
ELPA. And activate it via

--8<---------------cut here---------------start------------->8---
     (add-to-list 'tramp-connection-properties
                  (list (regexp-quote "/ssh:user@host:")
                        "direct-async-process" t))
--8<---------------cut here---------------end--------------->8---

> I would even consider using a lower level interface for accessing the
> remote system, where, for instance, I tell Tramp which of the 5 open
> ssh connection it should use for the next `file-attributes' call.

There's nothing to configure. `sile-attributes' is a synchronous
operation, it is performed always on the main Tramp process for a given
host. You could only try to keep Tramp caches, setting
remote-file-name-inhibit-cache to nil might help.

> Thanks in advance,
> Hendrik

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]