Question about additional find-file optimizations

[Julian Scheid]

Hi again,

as indicated in a previous mail I'm using Tramp a lot to work on
remote systems. For what it's worth, "remote" not as in somewhere else
on a Gigabit LAN, but as in 3,000 km away, via VPN over ADSL. This
means that any performance issues there are in Tramp become quite
pronounced for me: because I'm opening (and saving) a lot of files
daily using Tramp and because, even though my connection is fairly
good, latency and bandwidth are not like in a local network.

(And let me say preemptively that no, sshfs, NFS or similar are not
option for me for various reasons.)

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.

(I've actually managed to improve the round trip times from ~200 to
~120 ms by tweaking the process timeout (I'm using a Mac too) but that
doesn't really matter for the below.)

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

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.

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

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?

Thanks,

Julian