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

[Suhail Singh <suhailsingh247@gmail.com>]

Michael Albinus <michael.albinus@gmx.de> writes:

>>> Based on =profiler-report=, the following function "chains" consume most of the
>>> CPU:
>>> - `font-lock-fontify-keywords-region'
>>>   - tramp-sh-file-name-handler
>>>     - tramp-sh-handle-file-truename
>>>       - `tramp-wait-for-regexp'
>>>     - tramp-sh-handle-file-exists-p
>>>       - `tramp-wait-for-regexp'
>>>     - tramp-sh-handle-file-directory-p
>>>       - `tramp-wait-for-regexp'
>>>     - tramp-sh-handle-file-attributes
>>>       - `tramp-wait-for-regexp'
>>>
>>> As noted previously, disabling global-font-lock-mode helps.
>>
>> FWIW, I cannot reproduce this: I tried Dired on a remote host with
>> which I have connection that is quite slow, and saw neither high CPU
>> usage nor a significant delay in displaying a Dired buffer.
>
> It seems to be related to font-locking, indeed. See variable
> `dired-font-lock-keywords'. It specifies face recognition running basic
> file oprtations. For example, ";; Broken Symbolic link" calls
> `file-truename' and `file-exists-p', while "Symbolic link to a directory"
> and ";; Symbolic link to a non-directory" invoke `file-truename' and
> `file-directory-p'.
>
> I believe it would be helpful to suppress these checks via a user
> option.

I agree.  Having a user configuration(s) that allows one to selectively
disable some of the possibly more expensive checks would be valuable.
If that were available, user configuration code could determine their
own rules or thresholds as to when those options should be toggled
(without disabling font-locking in its entirety).

If performance degradation could be dynamically checked by Emacs
(something akin to so-long-action and so-long-predicate, but for this
instance of font-locking instead) that would be ideal, but it may not be
easy to implement and it certainly isn't necessary - when things get
unresponsive, it's pretty apparent.

> And no, the checks shouldn't be suppressed for remote directories in
> general, on a fast connection they are valuable.

I agree.

> In bug#17064, the impact of these calls where discussed. The conclusion was
>
>> Or could this have any bad side effects?  Is it maybe too heavy to call
>> `file-truename'?
>
> Normally, there aren't many symlinks in a buffer, so I think the
> performance impact would be negligible.
>
> Likely, this was too optimistic ...

For the host where I noticed this issue, the directory in question had
22 symlinks.

-- 
Suhail