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 #17 received at 73046 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 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: Fri, 06 Sep 2024 15:23:57 +0200

Eli Zaretskii <eliz <at> 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.

Previous Next

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