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: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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: Fri, 13 Sep 2024 19:17:36 -0400

Michael Albinus <michael.albinus <at> gmx.de> writes:

> I've added (sit-for 0.005) in the loop calling
> tramp-accept-process-output. It decreases the CPU load from 100% to
> something between 45..50%, when waiting for a response from
> remote. Pushed to master

I tested this patch today atop TRAMP 2.7.1.2.  Some findings:

1. If directory with symlinks on remote host with slow connection is
   opened CPU usage is much less than 100%.  That's the good news.
   However, there are a couple of caveats.

2. If we are in parent directory, and soon after pressing RET we invoke
   M-x we don't see the minibuffer prompt till after the offending
   directory has finished font-locking.

3. If after invoking M-x we immediately start typing, the keyboard input
   is registered, however, it doesn't display in the minibuffer till
   after the offending directory has finished font-locking.
   Additionally, doing so invariably results in 100% CPU usage for the
   duration of the font-locking.  Sometimes invoking M-x alone results
   in CPU usage going back up to 100% (while font-locking is still being
   done).

Thoughts?

-- 
Suhail

Previous Next

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