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

From: Michael Albinus <[email-masked]>
Date: Sat, 14 Sep 2024 09:07:29 +0200

Suhail Singh <[email-masked]> writes:

Hi Suhail,

>> 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.

But there is also the message from Jake Nelson, reporting problems with
the (sit-for ...) clause.

Yesterday, I ran some regression tests. When (sit-for ...) is activated,
there are serious performance degadations. So I've deactivated it in
master; it must be revised more carefully before activating it, again.

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

No. Yesterday evening, my doctor started a new torture with me. This
will last about a week; I fear I cannot work during that time. Sorry.

Best regards, Michael.