Czy istnieje sposób na poprawę wydajności trampa emacs? U mnie szybciej jest otworzyć zewnętrznego klienta ftp (filezilla), przenieść pliki na dysk lokalny i otworzyć je w zewnętrznym edytorze (notatniku), niż otworzyć emacsem. Używam emacs23.1 pod Windows XP. Próbowałem innej metody domyślnej tramp (telnet, pscp, ftp), wszystkie mają taką samą wydajność.wydajność emacsa tramp
Profilowanie wyniki z ELP-Instrument-pakietu są następujące (I otworzyła 3 zdalnych plików z 1,5 MB każdy)
tramp-file-name-handler 1461 350.41599999 0.2398466803
tramp-sh-file-name-handler 1461 350.02699999 0.2395804243
tramp-send-command 227 179.63400000 0.7913392070
tramp-send-command-and-check 205 177.77600000 0.8672000000
tramp-wait-for-regexp 227 176.47800000 0.7774361233
tramp-wait-for-output 226 176.40000000 0.7805309734
tramp-barf-unless-okay 18 133.46699999 7.4148333333
tramp-handle-insert-file-contents 3 132.046 44.015333333
tramp-handle-file-local-copy 3 131.281 43.760333333
tramp-accept-process-output 2375 112.95100000 0.0475583157
więc rzeczywisty transfer plików trwa 132 s, około 1/3 całkowitego czasu . Dlaczego spędza tak dużo czasu w programie obsługi tramp-sh-file-name-handler? Próbowałem doradzić funkcję tramp-sh-file-name-handler do przechowywania i zwracania wyników z pamięci podręcznej, ale to nie działa, prawdopodobnie ta funkcja ma pewne skutki uboczne.
Jakieś pomysły na poprawę wydajności trampów? (Używam emacs 23.1 pod WindowsXP)
Wyniki profilowania elp są "inclusive"; jakakolwiek funkcja tramp-file-name-handler calls pojawia się w danych czasowych. Zasadniczo spędzasz połowę czasu, czekając na IO, a druga połowa robi coś. Po prostu radzę sobie z tymi rzeczami na poziomie systemu operacyjnego; sshfs dla Linux, SFTPDrive dla Windows, itp. – jrockway