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


Message #155 received at 73046 <at> debbugs.gnu.org (full text, mbox):

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Suhail Singh <suhailsingh247 <at> gmail.com>,
 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: Sat, 14 Sep 2024 10:39:45 -0400
Michael Albinus <michael.albinus <at> gmx.de> writes:

>> 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.
>
> But there is also the message from Jake Nelson, reporting problems with
> the (sit-for ...) clause.

Could you please share the reference to that message (at your
convenience)?

> Yesterday, I ran some regression tests. When (sit-for ...) is activated,
> there are serious performance degadations. So I've deactivated it in
> master; it must be revised more carefully before activating it, again.

That's my impression as well.

>> 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?
>
> No. Yesterday evening, my doctor started a new torture with me. This
> will last about a week; I fear I cannot work during that time. Sorry.

I hope it all goes well; get well soon!

Please take your time on this.  The `dired-font-lock-keywords' tweak
effectively reduces the severity of the issue.  When you do have an
updated patch, I'll be happy to run some tests as needed.

Regards,
-- 
Suhail




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.