Eli Zaretskii <e...@gnu.org> writes: Hi,
>> >> It would also help if being over a slow connection didn't result in >> >> Emacs consuming 100% of the CPU via functions such as >> >> `tramp-wait-for-regexp' (based on profiler-report). Could some of this >> >> be done asynchronously? >> > >> > You could probably tell which parts take the time by profiling Emacs >> > while it collects the Dired data, using profiler.el. This could give >> > clues about the expensive parts. My guess would be that retrieving >> > the attributes of the files Dired needs are the reason, but I could be >> > wrong. >> >> Based on =profiler-report=, the following function "chains" consume most of >> the >> CPU: >> - `font-lock-fontify-keywords-region' >> - tramp-sh-file-name-handler >> - tramp-sh-handle-file-truename >> - `tramp-wait-for-regexp' >> - tramp-sh-handle-file-exists-p >> - `tramp-wait-for-regexp' >> - tramp-sh-handle-file-directory-p >> - `tramp-wait-for-regexp' >> - tramp-sh-handle-file-attributes >> - `tramp-wait-for-regexp' >> >> As noted previously, disabling global-font-lock-mode helps. > > FWIW, I cannot reproduce this: I tried Dired on a remote host with > which I have connection that is quite slow, and saw neither high CPU > usage nor a significant delay in displaying a Dired buffer. It seems to be related to font-locking, indeed. See variable `dired-font-lock-keywords'. It specifies face recognition running basic file oprtations. For example, ";; Broken Symbolic link" calls `file-truename' and `file-exists-p', while "Symbolic link to a directory" and ";; Symbolic link to a non-directory" invoke `file-truename' and `file-directory-p'. I believe it would be helpful to suppress these checks via a user option. And no, the checks shouldn't be suppressed for remote directories in general, on a fast connection they are valuable. In bug#17064, the impact of these calls where discussed. The conclusion was --8<---------------cut here---------------start------------->8--- > Or could this have any bad side effects? Is it maybe too heavy to call > `file-truename'? Normally, there aren't many symlinks in a buffer, so I think the performance impact would be negligible. --8<---------------cut here---------------end--------------->8--- Likely, this was too optimistic ... Best regards, Michael.
