JD Smith <[email protected]> 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.
