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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Suhail Singh" <suhailsingh247 <at> gmail.com>
Cc: 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: Thu, 05 Sep 2024 18:56:33 +0300

> From: "Suhail Singh" <suhailsingh247 <at> gmail.com>
> Date: Thu, 05 Sep 2024 10:24:54 -0400
> 
> 
> I observe 100% CPU usage for several seconds when invoking dired for a
> directory on one of the remote machines I connect to.  This doesn't seem
> to happen for another host.  The connection to the affected host is
> slower, and on that host the issue is worse when the directory has
> several symlinks.
> 
> To reproduce via =emacs -Q=:
> - Invoke `find-file' and connect to problematic host over ssh.
> - Once connection is established, open dired pointing to a directory on
>   the affected host.
> - Observe bug: it takes _several_ seconds for the dired buffer to show.
>   During that time, Emacs CPU usage is 100%.
> - Once dired buffer is open, invoke `revert-buffer' and observe issue
>   again.
> 
> Disabling global-font-lock-mode, makes the situation better.
> 
> Given that rudimentary font-locking should be possible via, simply, the
> output of `ls --dired', it is unclear why enabling font-locking makes
> things so much worse.  If there are some aspects of font-locking that
> perform much worse over a slower connection, it would help if there were
> a user configuration to disable them.
> 
> 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.

Previous Next

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