Re: Question about additional find-file optimizations

[Michael Albinus]

Julian Scheid <address@hidden> writes:

> Hi again,

Hi,

> Tramp works surprisingly well for me in spite of the delays but I see
> some room for improvement. As I hinted at in the previous mail,
> opening even small files takes around 3 to 4 seconds in my
> environment. I just took some time analyzing Tramp debug output to see
> where that time's coming from. Here's an example breakdown:
>
> test -e <file>           210 ms
> test -d <file>           200 ms
> stat -c <file>           300 ms
> tramp_perl_encode        310 ms
> test -w <file>           210 ms
> test -r <file>           310 ms
> tramp_bash_vc_files      400 ms  (formerly 12000ms or so)
> are you awake            200 ms
> cd                       200 ms
> git ls-files             200 ms
> echo tramp-exit-status   200 ms
> cd                       200 ms
> git ls-tree              200 ms
> echo tramp-exit-status   200 ms
>                         -------
>                         3840 ms
>
> This is a small (16 K) file under git control.
>
> Here are some optimizations I think I can see:
>
> If all "test" operations, e.g. file-exists-p, would instead do a full
> stat and put the result in the cache, all the tests could be collapsed
> into a single remote operation. Savings: ~900 ms

That's possible for test -e and test -d. test -r and test -w cannot be
replaced, because you don't know all group memberships of the user.

> I'm not sure why tramp-maybe-open-connection sends "are you awake"
> even though there was traffic on the line just before. If this could
> be fixed, 200ms less.

This check is done every 60sec in order to see, whether the connection
is still alive. Maybe it shall be done customizable. If it happens more
often (I haven't checked), there might be a bug.

> If the cd and the exit status echo could somehow be collapsed into the
> remote process invocation, this would save another 800ms.

Yep.

> Total potential savings: 1900ms, cutting time to open a file in half.
>
> Do you see any reasons why these optimizations could not be put in
> place? If I were to spend time on implementing these optimizations,
> would you be willing to incorporate them?

I will happily integrate your proposed patches. However, there is a
formal burden: Tramp is copyrighted to the FSF. All non-trivial patches
(larger than ~15 lines) require signing FSF papers.

> Thanks,
>
> Julian

Best regards, Michael.