JD Smith <jdtsm...@gmail.com> writes: Hi,
> Thanks very much for this much improved testing code (which also saves > the tedium of slowly retyping!). I altered it slightly to include a > few more function, and target my local wired server: > > (progn > (require 'tramp-sh) > (tramp-cleanup-all-connections) > (elp-instrument-list '(file-exists-p completing-read > read-file-name-internal read-file-name-default > tramp-handle-file-name-completion > tramp-sh-handle-file-name-all-completions)) > (setq unread-command-events (mapcar 'identity > "///ssh:datpi:/home/pi/no\tex\t/do\tma\tce\t\n")) > (call-interactively #'find-file) > (elp-results) > (elp-reset-all)) I've applied the same, except the remote file name. My timing results (emacs -Q, v28.0.50): >From *scratch*: read-file-name-default 1 9.064781548 9.064781548 completing-read 1 9.057834631 9.057834631 tramp-handle-file-name-completion 3 8.331385864 2.7771286213 tramp-sh-handle-file-name-all-completions 4 7.290909892 1.822727473 file-exists-p 45 1.7296832099 0.0384374046 read-file-name-internal 13 0.4099991600 0.0315383969 >From remote dired: read-file-name-default 1 8.23891833 8.23891833 completing-read 1 8.228419034 8.228419034 tramp-handle-file-name-completion 3 7.4998795480 2.4999598493 tramp-sh-handle-file-name-all-completions 4 6.463144493 1.6157861232 file-exists-p 45 1.6901479139 0.0375588425 read-file-name-internal 13 0.3952138859 0.0304010681 > So really only very little difference inside the tramp completion > functions; they seem to be doing the same job independent of the > starting point. But the completing-read itself, which is where > find-file is spending its time, is taking 8x longer! And > read-file-name-internal is 35x slower. Do you find this as well? > I’ll dig a bit deeper and see if I can narrow it down further. With Emacs 28, the differences aren't so relevant. The absolute time is much higher than in your case, but I have taken "savannah" as test host which is "far from me". Do you have a chance to compile Emacs from git, and run the test? Best regards, Michael.
