Eli Zaretskii <e...@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
