slow startup of tramp

slow startup of tramp

[Julien Oster]

Hello,

I learned to love tramp, the package where I can remotely edit files
via a shell interface, through ssh or even su.

However, when opening the first file on a remote host (or just trying
to do TAB completion to find the file), tramp takes a long time to
start up. During the startup, all sorts of information which tramp
gathered about the shell is displayed.

It (normally) doesn't ask for a password, since I'm using ssh with
public/private key authentication and ssh agents.

Also, the connection to the hosts where I'm using tramp is usually
very fast.

So why does tramp take such a long time to start up remote
connections? It even does this when I use "/su::/" which works locally
on my fast machine and doesn't use network at all!

Is there anything I can do to make it fire connections faster? Once
the shell connection is established, everything's fine.

Regards,
Julien

Re: slow startup of tramp

[Daniel Pittman]

On 25 Sep 2004, Julien Oster wrote:
> I learned to love tramp, the package where I can remotely edit files
> via a shell interface, through ssh or even su.
>
> However, when opening the first file on a remote host (or just trying
> to do TAB completion to find the file), tramp takes a long time to
> start up. During the startup, all sorts of information which tramp
> gathered about the shell is displayed.

[...]

> So why does tramp take such a long time to start up remote
> connections? 

I have not looked at the code recently, but when I worked on it there
were two reasons:

1. We needed to know a *lot* about the environment at the far end, and
   could assume *nothing* about it.

2. We did all the testing synchronously.

> It even does this when I use "/su::/" which works locally
> on my fast machine and doesn't use network at all!
>
> Is there anything I can do to make it fire connections faster? 

Not really, I fear, without getting down into the TRAMP code itself.

You could rewrite the testing routines to do the majority of the work on
the remote side of the connection, or consider some sort of Perl-based
"server" mode that could be sent if a remote Perl instance could be
discovered.

Regards,
        Daniel
-- 
It is well to remember that the entire universe, with one trifling exception,
is composed of others.
        -- John Andrew Holmes

Re: slow startup of tramp

[Kai Grossjohann]

Julien Oster <usenet-20040924@usenet.frodoid.org> writes:

> So why does tramp take such a long time to start up remote
> connections?

Daniel's remarks are right on target.  If you set tramp-verbose to 10,
you will see the shell commands sent, and once you recognize their
number, you will know why it takes long...

Daniel has made some of that code a lot faster by sending a chunk of
shell code that does a lot of detecting, then prints the result.  I
think that approach can be taken further by grouping more commands
into a single shell command that can be sent to the remote end.

Another approach that people talk about is to cache the results of the
detecting, and to reuse them on the next connection.

But all of this requires hacking the code.  I'm happy about all
contributions.

Kai