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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: suhailsingh247 <at> gmail.com, 73046 <at> debbugs.gnu.org
Subject: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Date: Sat, 07 Sep 2024 18:07:17 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Suhail Singh <suhailsingh247 <at> gmail.com>,  73046 <at> debbugs.gnu.org
> Date: Sat, 07 Sep 2024 16:36:42 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Michael, what do these checks entail, and why are they so
> > CPU-expensive and take a lot of time with slow connections?
> 
> I made a test. In a remote directory I have created a cyclic symlink
> "zzz", in order to see what Tramp does when running dired on the
> directory. The additional actions are
> [...]
> 15 times the "test -h" command - I guess, Tramp shall do cyclic link
> detection better.

I agree.  But that only explains the time delay, no why Emacs is
consuming 100% of CPU, right?  Waiting for the network should not
consume CPU, unless I'm missing something.

Also, Suhail Singh says that there's a significant delay when there
are valid symlinks, in which case I don't expect Tramp to issue the
same command 15 times, right?

I'm sorry to insist on understanding these fine details, but my
experience is that without a good understanding of a problem we might
devise a solution that is only a partial one.

Thanks.

Previous Next

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