-
Notifications
You must be signed in to change notification settings - Fork 39.2k
ripgrep file search uses too many threads #206030
Copy link
Copy link
Closed
Labels
feature-requestRequest for new features or functionalityRequest for new features or functionalityinsiders-releasedPatch has been released in VS Code InsidersPatch has been released in VS Code InsiderssearchSearch widget and operation issuesSearch widget and operation issuesverification-neededVerification of issue is requestedVerification of issue is requestedverifiedVerification succeededVerification succeeded
Milestone
Metadata
Metadata
Assignees
Labels
feature-requestRequest for new features or functionalityRequest for new features or functionalityinsiders-releasedPatch has been released in VS Code InsidersPatch has been released in VS Code InsiderssearchSearch widget and operation issuesSearch widget and operation issuesverification-neededVerification of issue is requestedVerification of issue is requestedverifiedVerification succeededVerification succeeded
vscode appears to use ripgrep for file searches in two places: ripgrepTextSearchEngine.ts and ripgrepFileSearch.ts. ripgrep has a
-j/--threadsargument with a default value of 0, which "causes ripgrep to choose the thread count using heuristics", which is to say that it's implicitly multithreaded with some unknown number of threads.I believe this is the root cause of a number of other issues filed with excessive CPU/memory usage by ripgrep (e.g. #203425), though certainly launching too many rg processes can be a problem regardless.
One issue I haven't seen reported is that on a distributed file system, having too many file search threads running simultaneously can severely degrade performance. In fact we're seeing a single user able to cause a weka filesystem to hang for a minute or more just through a remote VScode session launching one or two ripgrep processes.
I'd like to request a configuration option to set the number of threads (the
-jargument torg) wherever ripgrep is used. I'd prefer the default to be 1 to disable implicit multithreading, but 0 would be fine as long as the configuration option exists.