search

yzhang-gh / vscode-markdown

Markdown All in One
https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one
MIT License
2.91k stars 322 forks source link

rg.exe CPU 100% load #1001

Open irvnriir opened 3 years ago

irvnriir commented 3 years ago

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 .

yzhang-gh commented 3 years ago

It doesn't look like a problem that is caused by this extension.

I would suggest

Other information: https://code.visualstudio.com/blogs/2021/02/16/extension-bisect

irvnriir commented 3 years ago

disable all other extensions but not this one and check whether it happens

I've found this happening only when this extension is enabled .

irvnriir commented 3 years ago

Also, forgot to mention, i use Symbolic Links actively .

yzhang-gh commented 3 years ago

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)

irvnriir commented 3 years ago

As i repeatedly described, this happens randomly, its likely tied to some limit or time events, not directly to user actions .

yzhang-gh commented 3 years ago

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)

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.)

irvnriir commented 3 years ago

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) .

irvnriir commented 3 years ago

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)

Screenshot

yzhang-gh commented 3 years ago

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

GeoMaciolek commented 3 years ago

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!)

irvnriir commented 2 years ago

@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 .

bmingles commented 1 year ago

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.

yzhang-gh commented 1 year ago

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?

Chronostasys commented 1 year ago

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.

yzhang-gh commented 1 year ago

Thanks. Currently we are using the VS Code's API to find image files

image

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.)

Kolobok12309 commented 4 months ago

@yzhang-gh Big thanks, small debug and change search.exclude(add **/.nuxt) fix biiiig performance troubles