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

Previous Next

Package: emacs;

Reported by: "Suhail Singh" <suhailsingh247 <at> gmail.com>

Date: Thu, 5 Sep 2024 14:56:01 UTC

Severity: normal

Found in version 29.4

Fixed in version 31.1

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log


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

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 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: Fri, 06 Sep 2024 21:39:12 -0400
Suhail Singh <suhailsingh247 <at> gmail.com> writes:

>>>> 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.

For the benefit of others, absent such a user option, the below code
works around the issue:

#+begin_src emacs-lisp
  (add-hook 'dired-mode-hook
  	  (lambda ()
  	    (setq-local dired-font-lock-keywords
  			(cons
  			 (list dired-re-sym
  			       '(".+" (dired-move-to-filename) nil (0 dired-symlink-face)))
  			 (seq-remove (lambda (x)
  				       (string= (car x) dired-re-sym))
  				     dired-font-lock-keywords)))))
#+end_src

I believe that the above isn't a fix, but simply a workaround since
TRAMP awaiting a response over a slow connection shouldn't result in
100% CPU usage.  Functions such as `tramp-wait-for-regexp' should not be
using excess CPU when they are simply awaiting a response.

>>>> And no, the checks shouldn't be suppressed for remote directories
>>>> in general, on a fast connection they are valuable.

For this reason, those interested in working around the issue in a
similar manner as above, may want to add additional guards to the hook
to ensure that the informative font-locking is suppressed (by modifying
dired-font-lock-keywords) only when necessary.

-- 
Suhail




This bug report was last modified 240 days ago.

Previous Next


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