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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Sep 2024 09:24:07 +0300

> From: Suhail Singh <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [email-masked],
>   [email-masked]
> Date: Fri, 13 Sep 2024 19:17:36 -0400
> 
> Michael Albinus <[email-masked]> writes:
> 
> > I've added (sit-for 0.005) in the loop calling
> > tramp-accept-process-output. It decreases the CPU load from 100% to
> > something between 45..50%, when waiting for a response from
> > remote. Pushed to master
> 
> I tested this patch today atop TRAMP 2.7.1.2.  Some findings:
> 
> 1. If directory with symlinks on remote host with slow connection is
>    opened CPU usage is much less than 100%.  That's the good news.
>    However, there are a couple of caveats.
> 
> 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?

And what do you expect to happen when you press M-x while Emacs is
still busy performing your previous command?  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.