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

[Suhail Singh <suhailsingh247@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 15 times the "test -h" command - I guess, Tramp shall do cyclic link
>> detection better.
>
> 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.

-- 
Suhail