bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

[Michael Albinus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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.