Tramp performance (was: Emacs unconditionally loads tramp.el)

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

David Kastrup <dak@gnu.org> writes:

>> In my experience tramp is _much_ slower than even ange-ftp (in all
>> ways, but especially establishing connections).  I think this
>> severely limits its utility for general use, and potential audience.
>
> The thing I find annoying is how slow it is for establishing a local
> connection, like with /su::/etc/fstab.  Should be instantaneously,
> really.

Tramp doesn't make a special handling for su(do)? methods. It runs all
the initialization commands, like being in the terra incognita of a
remote host. Changing this, could be an optimization, indeed.

There are other optimizations planned, like keeping a connection
history, in order to reduce the number of checks to be performed.

But: Tramp 2.0, as integrated in GNU Emacs 22, is in maintenance
mode. No new development shall happen there.

Tramp 2.1 has experienced several optimizations already, for example
reducing the number of commands to be sent, delaying checks until they
are needed, and file attributes caching. Some months ago I've
published comparison data, see commentary in
<http://cvs.savannah.gnu.org/viewcvs/tramp/test/tramp-time.el?rev=1.4&root=tramp&view=markup>.

It has been asked sometimes whether Tramp 2.1 could be integrated into
GNU Emacs 22. I've refused it always, because of stability, and
because there are other experimental features which need further
development before going to mainstream use.

If performance of Tramp is a critical issue for acceptance, we could
revise this decision. It should be simple to deactivate (not remove
the code of) the experimental features, because all needed defadvices
are in tramp-util.el. When this file is not present, Tramp won't use
that code.

But stability. Tramp 2.1 code basis is remarkable different from Tramp
2.0. It is used by several people, but I really don't know whether it
is a good decision to integrate it into GNU Emacs 22 so short before
the release.

Best regards, Michael.