Alexander-Miller / treemacs

GNU General Public License v3.0
2.11k stars 155 forks source link

Treemacs consuming 100% CPU / Treemacs is querying texlab unnecessarily #747

Closed frgomes closed 3 years ago

frgomes commented 3 years ago

Apparently, treemacs queries all LSP components it knows of, even when not necessary. I said "apparently" since my investigation was superficial and I know nothing about the codebase of treemacs. More details:

Related

https://github.com/frgomes/.emacs.d/issues/9

Troubleshooting

I've observed 100% CPU utilization caused by treemacs. From my very very limited knowledge of treemacs, I've turned off a couple of parameters but the problem persisted.

I was coding in Rust, and I've decided to rename rls (the LSP component for Rust) so that treemacs would not find it. The problem persisted.

Then I've tried something which was in the back of my head since the morning: I'm using openSUSE Tumbleweed, which performed a rolling update containing 1344 texlive packages. I don't need texlive at all and I was thinking about removing them. So, as a sake of test, I've first renamed textlab (the LSP component for LaTeX) so that treemacs would not be able to find it.

This solved the issue. After that, I was convinced that removing texlive is what I need.

About this issue

So, why treemacs queries texlab (for symbols related to LaTeX) when I'm coding in Rust and only querying rls would be theoretically sufficient? Am I mistaken about that?

Bug or a feature?

More info

Distribution: openSUSE Tumbleweed (rolling updates) Linux kernel: 5.9.10-1 Treemacs version: [Treemacs] v2.8 (installed 2020.11.27) @ Emacs 27.1

My .emacs.d is here

frgomes commented 3 years ago

Complementing the initial report:

I've observed that, even removing all texlive packages, the slowness still persists, reaching 100% CPU. I've then renamed texlab so that treemacs cannot find it. Then the issue vanishes. Some more edits and trying to do resume my work.... and I stumble with 100% CPU usage once again.

Conclusion: I'm not able to tell if the root cause of slowness is treemacs or something else.

Some more investigation:

I have another box running Debian Buster. I will refresh my .emacs.d there folder so that all updated sources will be retrieved once again from MELPA, etc and recompiled. This will isolate changes in the operating system from changes in treemacs and could eventually help isolate the problem. I will post more on the matter later.

Alexander-Miller commented 3 years ago

So, why treemacs queries texlab (for symbols related to LaTeX) when I'm coding in Rust and only querying rls would be theoretically sufficient? Am I mistaken about that?

Treemacs doesn't do that. At the most treemacs can ask for a buffer's symbol list, but that must be done manually and uses the builtin imenu feature. The problem must be somewhere in the connection with the language server. And that is not something I can help you with on my own. Treemacs' connection with lsp-mode is that treemacs provides a generic extensions api that is used by lsp-treemacs to display features like hierarchical symbol trees.

In other words: treemacs gets told what to do, but the process of finding, sorting and filtering items for treemacs to show, and deciding when and how often to do so, lies in the hands of lsp-treemacs. I suggest raising the issue over there as well and putting me on CC.

In addition there's 2 important pieces of information that will be very useful for solving this:

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.