bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening d


From: Michael Albinus
Subject: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP
Date: Sat, 21 Sep 2024 10:30:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Version: 31.1

Michael Albinus <michael.albinus@gmx.de> 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.

I've tried (sleep-for 0), but this doesn't help. CPU load is always 100%,
even if there is no input.

So I've pushed (sit-for 0) to master. Unless Eli has a better proposal,
I'm done with this.

It will also be available in Tramp 2.7.1.3, scheduled for release on GNU
ELPA end of this month.

Closing the bug.

Best regards, Michael.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]