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

From: Michael Albinus <[email-masked]>
Date: Sun, 08 Sep 2024 13:30:00 +0200

Suhail Singh <[email-masked]> writes:

Hi,

>> I agree.  But that only explains the time delay, no why Emacs is
>> consuming 100% of CPU, right?  Waiting for the network should not
>> consume CPU, unless I'm missing something.
>>
>> Also, Suhail Singh says that there's a significant delay when there
>> are valid symlinks, in which case I don't expect Tramp to issue the
>> same command 15 times, right?
>
> Yes, while there are clearly inefficiencies in cyclic link detection,
> that's not the situation for the reproducer I shared.  Font-locking
> symlinks (broken, not broken; to files, to directories) trigger the
> issue even without introducing cyclic references.  For what it's worth,
> as I shared in an earlier exchange, the profiler-report seemed to point
> the finger to `tramp-wait-for-regexp':
>
> | Func in font-lock check | TRAMP handler                                                        |
> |-------------------------+----------------------------------------------------------------------|
> | `file-truename'         | `tramp-sh-handle-file-truename' -> ... -> `tramp-wait-for-regexp'    |
> | `file-exists-p'         | `tramp-sh-handle-file-exists-p' -> ... -> `tramp-wait-for-regexp'    |
> | `file-directory-p'      | `tramp-sh-handle-file-directory-p' -> ... -> `tramp-wait-for-regexp' |
>
> Unless I misinterpreted the profiler output, something in/about
> `tramp-wait-for-regexp' results in the 100% CPU usage.

Tramp is in a loop, waiting for results from the remote side. I don't
know how to implement this differently.

Best regards, Michael.