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: Michael Albinus <michael.albinus <at> gmx.de>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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, 20 Sep 2024 17:35:41 +0200

Suhail Singh <suhailsingh247 <at> gmail.com> writes:

Hi Suhail,

> On a related, but distinct note, thoughts on whether there's a
> relatively straightforward way to address "3" below (from one of the
> other exchanges in this thread)?
>
>>> >> 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).
>>>
>>> > And what do you expect to happen when you press M-x while Emacs is
>>> > still busy performing your previous command?
>>>
>>> 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.
>>
>> If 3 surprised you, then the reason is simple: sit-for returns
>> immediately if any input is available, so typing effectively disables
>> the wait.  This could be countermanded by unconditional sleep, but
>> AFAIU Michael is rethinking the whole issue, so we should wait for him
>> to reach his conclusions.

This would mean to use (sleep-for 0) instead of (sit-for 0), right? Hmm,
I might try the same tests for this clause next days, no idea whether it
makes a difference.

But ATM, we should use (sit-for 0), until we know better.

Best regards, Michael.

Previous Next

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