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

[Suhail Singh <suhailsingh247@gmail.com>]

Michael Albinus <michael.albinus@gmx.de> writes:

> 4. Use (sit-for 0) in `tramp-wait-for-regexp'.
>
> Emacs consumes 72% .. 74% CPU, the same as in 3. The test suite reports
>
>    passed  1/2  tramp-test11-copy-file (1.562353 sec)
>    passed  2/2  tramp-test12-rename-file (1.626922 sec)
>
> Seems to be the best compromise, I'm in the mood to apply.
>
> Comments?

Seems like a reasonable compromise.

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)?

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Suhail Singh <suhailsingh247@gmail.com>
>> Cc: Suhail Singh <suhailsingh247@gmail.com>,  michael.albinus@gmx.de,
>>   73046@debbugs.gnu.org
>> Date: Sat, 14 Sep 2024 10:25:13 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> 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 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.


-- 
Suhail