search

Gruntfuggly / todo-tree

Use ripgrep to find TODO tags and display the results in a tree view
Other
1.42k stars 137 forks source link

Why rg.exe always has a high I/O usage? #636

Open crasylph opened 2 years ago

crasylph commented 2 years ago

With todo-tree, rg.exe always has a hard disk reading speed of 10.0 MBps or even more, which makes my system extremely slow. Is it normal?

aharpervc commented 1 year ago

I noticed this myself during a git rebase, where vs code was spawning tons of rg processes, and it was slaughtering performance. I had to disable this extension, unfortunately

TastePurple commented 1 year ago

Same issue. Using a Remote SSH connection to CentOS 7 with enableFileWatcher: true. When executing a task that changes a large number of files, this extension will spawn multiple ripgrep (rg) processes which all go to a 'zombie' state and drive the node CPU to 100%. When executing a task will a moderate number of file changes, the rg processes appear to eventually get their exit status read and the node will eventually return to idle. However, after large file count changes, the node does not resolve after 15 minutes so it's effectively hung. With enableFileWatcher: false, this issue is not present.

Gruntfuggly commented 1 year ago

Do you have "todo-tree.general.enableFileWatcher" enabled?

TastePurple commented 1 year ago

Yes. "todo-tree.general.enableFileWatcher" is the source of the issue. Setting to false allows for continued use of the extension which is great because I really like this extension (thank you for the effort). With file watcher enabled, it actually locks the node such that VSCode becomes unusable and requires the Linux node to be terminated. The multiple ripgrep processes just hang out forever waiting for the node to check their return status. If there's any diagnostics I can provide, please let me know. The issue readily reproducible on my configuration. Is there a limit to the number of ripgrep processes that the file watcher can spawn?

Gruntfuggly commented 1 year ago

I'm think I'm going to remove the file watcher functionality - it just causes problems and is not really useful except in very specific circumstances. I think people enable it thinking it will do something it doesn't.

TastePurple commented 1 year ago

That's probably true. I've been testing with file watcher disabled and the highlighting still works as soon as I type the keyword and it appears immediately in the list. What does file watcher do if not those 2 things?

Gruntfuggly commented 1 year ago

The file watcher only real purpose is to watch for files that might change outside of VSCode (via a build process for example). Its a tiny niche and not really worth supporting for the amount if grief it causes.