Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The 3.4.1 version is slowing down my full machine, looking at antora.yml with ripgrep in a large folder #921

Open
loic-joly-sonarsource opened this issue Oct 29, 2024 · 5 comments
Labels

Comments

@loic-joly-sonarsource
Copy link

My working folder contains thousands of subfolders. In one of the subfolders, I edit an asciidoc file. Each time I perform any edit, the 32 cores of my computer (on Windows) jump to 100% usage for several seconds.

image

When looking at the greedy process, I notice rg.exe, which is launched with the following command line:

"c:\Users\****\AppData\Local\Programs\Microsoft VS Code\resources\app\node_modules\@vscode\ripgrep\bin\rg.exe" --hidden --follow --files -g **/antora.yml

Going back to version 3.1.1 solves the issue.

@loic-joly-sonarsource loic-joly-sonarsource changed the title The 3.4.1 version is slowing down my full machine, looking at antora.xml with ripgrep in a large folder The 3.4.1 version is slowing down my full machine, looking at antora.yml with ripgrep in a large folder Oct 30, 2024
@ggrossetie
Copy link
Member

In theory, ripgrep should be faster (and consume less resources than vscode.workspace.findFiles. Could you please share some stats about your large folder? Do you have symlinks? How many files do you have? How many hidden files? How many antora.yml? How many directories?

If you manually run "c:\Users\****\AppData\Local\Programs\Microsoft VS Code\resources\app\node_modules\@vscode\ripgrep\bin\rg.exe" --hidden --follow --files -g **/antora.yml on your workspace folder, how long does it take?

@ggrossetie
Copy link
Member

Fixed in c854814. I'm keeping this issue open because at some point we might re-enable ripgrep and I want to make sure that it will not impact performance on some cases.

@loic-joly-sonarsource
Copy link
Author

This folder contains 21700 files, evenly spread out across 10700 directories. It does not contain any file named antora.yml, only one hidden folder (.git), and no symlink.
When I run the command manually, it takes ~2s. When I had the issue, I noticed there were several instances of that command running in parallel.

Is there any other info that might help you?

@ggrossetie
Copy link
Member

It does not contain any file named antora.yml

I guess you should disable Antora support. I think, we might have (unexpectedly) enable Antora support by default in 3.4.1 that's probably why you weren't seeing this issue in 3.1.1 (because Antora was disabled and the extension wasn't looking for antora.yml files). I believe that running findFiles in a folder containing 21700 files, evenly spread out across 10700 directories while take way more than 2seconds.

I noticed there were several instances of that command running in parallel

Do you know if all instances where using the same glob expression? We were using ripgrip in a few places.
We are aware that Antora support is currently not efficient/performant and that we are probably searching for antora.yml files way too often.

Anyway, if you are not using Antora, make sure to disable it using the command: AsciiDoc > Disable Antora support in this workspace.
Before doing that, if you could upgrade to 3.4.2 and report if you are still experiencing this performance issue?

Thanks!

@loic-joly-sonarsource
Copy link
Author

Switching to 3.4.2 mostly solves the issue. I still have CPU spikes, but they are much smaller.

Going back to 3.4.1:

  • I looked at several rg runs, they were all about antora.yml.
  • It's hard to count, but about 7 rg.exe processes were started with each keystroke.
  • Disabling Antora support works great, no spike at all.

I now went back to 3.4.2, with no support for Antora.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants