bug#70901: 30.0.50; Tramp doesn't use ControlMaster even with (setq tramp-use-connection-share nil)

[Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Hi Michael,

Hi Dmitry,

>> Well, the message is there not only waiting for the network
>> connection,
>> but also waiting for Tramp doing its initialization. So you cannot
>> compare the time with a simple "ssh ..." from the shell.
>
> But it looks very similar to the time "ssh ..." takes in the shell.
>
> Except when I set up ControlMaster for the host, "ssh ..." in the
> shell starts taking much less time (not having to establish a new
> connection, I take it).
>
> Whereas the time it takes for Tramp to finish "Connecting ..." seems
> unchanged.
>
>> Yes, because the majority of the time is spent in roundtrips during
>> initialization.
>
> Does that mean that, somehow, Tramp is faster at establishing the new
> connection than the terminal ssh?
>
> Then it would make sense that the rest of the time is taken by
> additional work.
>
>> Again, it isn't only the ControlMaster option. And it depends also,
>> whether there is already an existing connection, which can be reused.
>
> I test and compare by restarting Emacs at the beginning of each
> scenario, or killing the existing connection anyway.
>
> We're supposed to reuse the external connection established by
> ControlMaster, right? I mean, at least at the lower level of the
> implementation.

If we want to go into detail, we need a clean testbed. In your tests, I
don't know whether another connection already exists which Tramp could
reuse due to your ControlMaster settings. And we need to separate the
time the "ssh ..." call takes inside Tramp, from the other time when
Tramp does some roundtrips for the initialization. We must count the
time Tramp needs when tramp-verbose has a higher level. Etc pp.

Do we need this? We have seen that Tramp doesn't touch Control* options
when you set tramp-use-connection-share to nil. And that's what this bug
report is about.

There is always place for improvement, patches welcome! But for this
purpose, there is already bug#56342.

Best regards, Michael.