Suhail Singh <suhailsingh...@gmail.com> 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.
