GNU bug report logs - #73046
29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Previous Next

Full log

Message #56 received at 73046 <at> debbugs.gnu.org (full text, mbox):

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, Suhail Singh <suhailsingh247 <at> gmail.com>,
 73046 <at> debbugs.gnu.org
Subject: Re: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when
 opening dired buffer over TRAMP
Date: Sat, 07 Sep 2024 04:07:52 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks you.  So the problem seems to be symlinks, and specifically
> symlinks to directories.

After sending the penultimate email, and before sending the last (which
contained the workaround for modifying `dired-font-lock-keywords'
buffer-locally) I ran some more tests, and symbolic links to files are
also problematic.

Specifically, it's the three checks marked by the following comments in
`dired-font-lock-keywords' that are problematic:

- ";; Broken Symbolic link."
- ";; Symbolic link to a directory."
- ";; Symbolic link to a non-directory."

Only when the three entries corresponding to the above are removed from
`dired-font-lock-keywords', does the issue get resolved.  Removing some
(but not all) of the entries improves matters, but doesn't resolve them
completely.  Quoting Michael:

#+begin_quote
  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.
#+end_quote

> Michael, what does Tramp do specially in these cases that could
> explain the slowdown?
>
>> The above observations seem consistent with Michael's comments above
>> regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to
>> a directory".
>
> Michael, what do these checks entail, and why are they so
> CPU-expensive and take a lot of time with slow connections?

-- 
Suhail

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.