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


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: michael.albinus <at> gmx.de, 73046 <at> debbugs.gnu.org
Subject: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Date: Fri, 06 Sep 2024 22:08:23 +0300
> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Cc: suhailsingh247 <at> gmail.com,  Michael Albinus <michael.albinus <at> gmx.de>,
>   73046 <at> debbugs.gnu.org
> Date: Fri, 06 Sep 2024 13:47:54 -0400
> 
> > How long does it take to fetch a file of, say 20 KBytes?
> 
> Given a 20kb file generated via:
> #+begin_src sh :results verbatim
>   mkdir -p /tmp/test
>   cd /tmp/test
>   dd if=/dev/urandom of=upload_test bs=10k count=2
>   du -sh /tmp/test/upload_test
> #+end_src
> 
> #+RESULTS:
> : 20K	/tmp/test/upload_test
> 
> It takes ~4-6s to upload:
> #+begin_src sh :results verbatim
>   cd /tmp/test
>   {
>       time scp upload_test scp://${affected-host}//tmp/upload_test
>   } 2>&1
> #+end_src
> 
> #+RESULTS:
> : 
> : real	0m4.255s
> : user	0m0.008s
> : sys	0m0.002s
> 
> And a similar time to download:
> #+begin_src sh :results verbatim
>   cd /tmp/test
>   {
>       time scp scp://${affected-host}//tmp/upload_test ./download_test
>   } 2>&1
> #+end_src
> 
> #+RESULTS:
> : 
> : real	0m5.638s
> : user	0m0.007s
> : sys	0m0.000s
> 
> 
> > Also, if font-lock is disabled, does the problem go away?
> 
> As noted in the original message:
> 
> >>> Disabling global-font-lock-mode, makes the situation better.
> 
> Things are still sluggish after disabling font-lock, but they are *much*
> better (i.e., instead of a ~10s delay for revert-buffer we are down to
> less than a second).  The remaining sluggishness seems reasonable given
> what I know about the connection speed, but I have not done extensive
> quantitative testing.  As such, while I cannot say with certainty if
> "the problem" goes away entirely, or only mostly, it does improve
> significantly.

So if it takes 4 to 5 sec to move a 20KB file, then how much stuff
needs to be moved for the Dired listing?  What does the below show, if
you run it on that remote machine?

  $ ls -al | wc

It needs to show around 40KB to explain 10 sec of delay.




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.