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 #14 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: Fri, 06 Sep 2024 08:40:45 +0300

> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Cc: "Suhail Singh" <suhailsingh247 <at> gmail.com>,  73046 <at> debbugs.gnu.org
> Date: Thu, 05 Sep 2024 17:04:23 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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.

> In related news, one thing I've observed on the affected host is that
> the version of `ls' doesn't seem to yield expected output for
> `ls --dired'.  Specifically, the output of `ls --dired' is the same as
> the output of `ls' (i.e., `--dired' gets treated as a no-op).

This could indeed explain the problem.  However, ...

> The version of `ls' on this host is:
> 
> #+begin_quote
>   ls (GNU coreutils) 8.32
>   Copyright (C) 2020 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
>   This is free software: you are free to change and redistribute it.
>   There is NO WARRANTY, to the extent permitted by law.
> 
>   Written by Richard M. Stallman and David MacKenzie.
> #+end_quote

This cannot be true: the --dired option was added to 'ls' way earlier.
I have Coreutils 6.9 from 2007 on one of my systems, and --dired is
supported there.  To see if it is supported, try this:

  $ ls -al --dired

You should see 2 extra lines of output after the listing, each one
starting with "//DIRED".

Previous Next

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