yzhang-gh
rg.exe CPU 100% load
Problem
I've found this happening only when this extension is enabled .
How to reproduce
It happens when opening, editing or saving files . May require many folders present in workspace's open folders tree .
It doesn't look like a problem that is caused by this extension.
I would suggest
- disable all extensions and check whether it still happens
- disable all other extensions but not this one and check whether it happens
Other information: https://code.visualstudio.com/blogs/2021/02/16/extension-bisect
disable all other extensions but not this one and check whether it happens
I've found this happening only when this extension is enabled .
At first, I cannot reproduce this issue given such limited information. You need to help yourself otherwise no one knows what is wrong.
Here are some hints (assuming all other extensions have been disabled)
- does this happen if you open an empty Markdown file? (or it happens when you do nothing but just opening a folder?)
- as you already found, does this happen if you are working on a folder with no symbolic links?
As i repeatedly described, this happens randomly, its likely tied to some limit or time events, not directly to user actions .
What you tell us is
It just happens, randomly. It may relate to opening too many folders but you are not sure. It may relate to symbolic links but you are not sure. ...
If you cannot find any helpful information, no one can. (Only you can see it happens). If you would like to solve it, you need to spend some time "debugging" it (doing your controlled experiments) Try to find something (reproducible steps) that you are sure of.
Here are some hints (again, assuming all other extensions have been disabled)
- make sure the working folder has no symbolic links
- open an empty Markdown file, write something (only plain text, e.g.,
fjslkgflkg), save, delete something, save, close it - repeat it 5/10/... times until it happens
- or it doesn't happen at all?
If the issue still exists (in the above really simple test case), you may check just opening a folder and an empty document without any editing, wait and see whether the issue exists.
......
(I'm going to sleep now. Good luck.)
its likely tied to some limit or time events, not directly to user actions .
Each of these tests (tries) would last 15-40 minutes .
To solve such issue, the most logical way is check all commands which result to "rg.exe" calls, from extensions which can be outlined by doing long-term bisect , Such resulted extension is this one .
It also may be related to working with [name](path) assets (but again, its not consistent and usually will not happen when you just open a file and write this) .
Tried closed loop with Symbolic Links : creating, editing and saving, deleting, files and []() ; managing as workspace folder . Without waiting (right at start) doesn't cause anything . (i knew that already, but just in case)
It also may be related to working with
[name](path)assets
That was my hypothesis.
I don't expect any useful information anymore. Let's simply do this:
I will package a dev build that disables the auto-completion feature (which uses the VS Code's workspace.findFiles API).
If it solves your issue, good. But still, no one knows when and why this issue happens (only for you).
If it doesn't solve the issue, well, there is nothing more I can do.
maio-3.4.0-disables-completion.zip
rg.exe is used by VSCode's search feature for a bunch of stuff - but, I may be able to help you (both??) with this. @irvnriir - this means you - help us help you!
Short Version
Either use the windows task manager or SysInternals ProcMon to examine what rg.exe is doing, via (among other things)the command-line arguments. ProcMon can even get details if rg.exe exits before you can track stuff down!
Longer Version
Please consider installing ProcMon as detailed below FIRST; leaving it running will potentially help if the next bit itself doesn't.
Get The PID / Task Manager
If the CPU usage hits 100% and sits there, presumably you can find it in Windows Task Manager. When you're in the task manager, take note of the pid - it may be helpful with the next section! In the windows task manager (control-shift-escape, which you presumably know), click on the Details column. Right-click in the column header, Select Columns and add Command Line (probably 3/4 of the way to the bottom). This will add a column that will show the commandline arguments for the running processes. Take a look at rg.exe - you will likely need to expand the column width to see what commandline arguments are being passed. But, you may wish to just jump ahead to...
Using SysInternals Process Monitor
Install the Microsoft Sysinternals Process Monitor utility, aka procmon. (You can grab the entire suite or just procmon.
Install this, run it (elevated / as Administrator, I believe). Go to the Filter menu and tell it to filter by process name rg.exe. You'll also want to right-click on the column headers in the view, and enable the Command Line column.
This will run in the background, and will note every time that rg.exe runs - as well as some details on what it tries to open - files, registry keys, etc. And it will include the Command Line details - showing you how it was called. And, if you have the PID from the Task Manager, you can specifically look for that instance / call of rg.exe!
The command line arguments list will likely be too wide to display, but you can either export the results, or right-click it to get info. An example when doing normal VSCode searching through one of my codebases:
"c:\Program Files\Microsoft VS Code\resources\app\node_modules.asar.unpacked\vscode-ripgrep\bin\rg.exe" --hidden --ignore-case -g !**/.git -g !**/.svn -g !**/.hg -g !**/CVS -g !**/.DS_Store -g !**/node_modules -g !**/bower_components -g !**/*.code-search --max-filesize 17179869184 --no-ignore-parent --follow --crlf --fixed-strings --no-config --no-ignore-global --json -- zlx .
You can of course edit the results to make more sense of it, like this:
"c:\Program Files\Microsoft VS Code\resources\app\node_modules.asar.unpacked\vscode-ripgrep\bin\rg.exe"
--hidden
--ignore-case
# Here we see a series of paths it ignores - -g is "use this pattern" - the leading "!" means "NOT:
-g !**/.git
-g !**/.svn
-g !**/.hg
-g !**/CVS
-g !**/.DS_Store
-g !**/node_modules
-g !**/bower_components
-g !**/*.code-search
# Some more standard parameters
--max-filesize 17179869184
--no-ignore-parent
--follow
--crlf
--fixed-strings
--no-config
--no-ignore-global
--json
-- zlx
# And - the actual search path - "." aka the path it was called from / working directory
.
Next Steps
If you're able to get those command-line arguments (or any other seemingly-relevant details from procmon), you can share those here - even if you aren't able to track down the cause of the issue, we might be able to! (Plus, procmon is just a GREAT tool overall, for tracking down weird Windows stuff!)
@yzhang-gh i had to switch to my SSD (for other reason), now the load runs only for some seconds, but it present .
seems that the issue doesn't happen with the feature disabled .
I also see this issue specifically when I enable this extension. In my case it happens when I am building a typescript project. My theory is that it is caused by new files showing up in various /dist folders in my particular project. I see lots of rg.exe processes start up and vscode becomes stalled.
Thanks for the information. That is possible. Could you please check whether it still happens if you add these dist paths to the search.exclude option?
I'm facing this issue too. It happens when I build my rust project. I tried to add **/target to search.exclude, the issue persists.
Seems like this is caused by the auto completion feature, which try to monitor all file changes and create an index eagerly during file changing.
In my opinion, the completion shall be generate lazily, e.g. when user type /a, we try to get the state of /a directory.
Thanks. Currently we are using the VS Code's API to find image files
It would be better if you can find out which directory caused the issue. (Of course we can set the max number of results or timeout, but then we can never get the expected completions in this case.)
@yzhang-gh Big thanks, small debug and change search.exclude(add **/.nuxt) fix biiiig performance troubles
