Re: File path completions: strange speed discrepancy

[Michael Albinus]

JD Smith <jdtsmith@gmail.com> writes:

Hi,

>     Yes, there are still discrepancies in my tests (I'm running
>     GNU/Linux),
>     mainly in tramp-sh-handle-expand-file-name:
>
> I meant only that this darwin-shell-calling behavior hadn’t yet been
> fixed on those newer versions, but I anticipate 2.5.1.3 will fix it
> for v28.1 as well (for darwin users).  People with fast-starting
> shells (or users of sshx, which spawns its own /bin/sh) won’t likely
> notice any real difference (1.5-2x slowdown is harder to notice than
> 10-20x slowdown!).  
>
>     Running on "/"
>
>     read-file-name-default                          1          
>     0.866070978   0.866070978
>     completing-read                                 1          
>     0.864735142   0.864735142
>     completion-file-name-table                      21         
>     0.7882453620  0.0375354934
>     ...
>
>     Running on "/ssh::"
>
>     read-file-name-default                          1          
>     6.540671391   6.540671391
>     tramp-sh-handle-expand-file-name                408        
>     4.9722099110  0.0121867889
>     completing-read                                 1          
>     1.586810819   1.586810819
>     completion-file-name-table                      21         
>     1.3919740299  0.0662844776
>     ...
>
>     So there is still something to be investigated in
>     tramp-sh-handle-expand-file-name. But since this is the test case
>     we have
>     started on a remote default-directory, it might be OK. At least
>     the time
>     for tramp-sh-handle-expand-file-name is not cumulated in
>     completing-read. Will see.
>
> This is indeed strange, and oddly the reverse discrepancy of what I
> found (for me: remote was fast, local was slow). 

This has been explained. In my tests, I use one remote file name as
default-directory, and complete another remote file name, on another
host. So there has been additional cost to handle all these remote file
names. No further problem, now that it is clear.

> Best,
> JDS

Best regards, Michael.