tramp-devel
[Top][All Lists]
Advanced

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

Re: problem of `tramp-handle-file-local-copy' and inline transfer compre


From: Michael Albinus
Subject: Re: problem of `tramp-handle-file-local-copy' and inline transfer compressing
Date: Wed, 28 Apr 2010 10:05:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Toru TSUNEYOSHI <address@hidden> writes:

>> And why have you increased `tramp-copy-size-limit'? Are there
>> performance problems with the default value?
>
> (In my former message)
>
>   ;; with compress
>   => "6.61 secs"
>   => "4.516 secs"
>
>   ;; with pscp instead of plink
>   => "19.338 secs"
>   => "13.209 secs"
>   => "8.152 secs"
>   => "8.422 secs"
>   => "5.828 secs"
>
> According to the above result of my test (file size is 613kB), `plink'
> with compress is faster than `pscp'. And copy by `plink' don't need
> `login'.

That's true for text files. For binary files, compress won't decrease
the file size remarkable.

> In the other hand, if we use `pscp', by default, we must input password
> whenever `login' by the case. I don't know the way of automatic login
> without password input well. Maybe I need to read `info' for Tramp
> later, I think.

(info "(tramp)Password handling")

In your case, I would recommend

(setq password-cache t)

If possible, you might also try "scpc" or "rsyncc" methods. Those
methods reuse existing ssh connections for the copy operation.

I haven't found a similar feature in pscp yet, unfortunately.

> But, if any part of the patch is effective, plese make use of it.

I will check further. Maybe you are right, and inline compression is
more effective than scp/pscp. But it needs some more description in the
manual, how a user shall tune it.

> Thanks, Michael san. (san: honorific title in Japanese)

Thanks for your contribution, Toru san! Best regards, Michael.




reply via email to

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