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 #152 received at 73046 <at> debbugs.gnu.org (full text, mbox):

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 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:25:13 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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?
>
> Are 2 and 3 new with this patch, or were they present in the previous
> code as well?

Present prior to the patch as well.

> And what do you expect to happen when you press M-x while Emacs is
> still busy performing your previous command?

I did not have any expectations wrt 2.  I knew that it was possible that
2 was simply a limitation of the single-threaded reality of the current
implementation.  However, it wasn't clear (till now) whether that was
necessarily the case.

I did not expect 3 to happen.  I.e., wrt 3 my expectation was that
invoking M-x and typing doesn't result in a noticable increase in CPU
usage for the duration of the font-locking.

> Having the visual response delayed until the previous command finishes
> is normal Emacs behavior, being a single-threaded program which
> executes commands one by one in the same thread.

Understood.

-- 
Suhail

Previous Next

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