Result: 0.22 seconds. Ripgrep itself is instant. The bottleneck is in Cursor’s search UI rendering/processing layer, not ripgrep.
I also noticed Cursor runs 5 extension-host processes (agent-exec, user ×2, always-local, retrieval) consuming ~1.8 GB RAM, compared to 1–2 in VSCode. The main renderer process sits at ~16% CPU and ~930 MB RAM even when idle.
I’ve tried the following with no improvement:
Disabled Codebase Indexing in Cursor Settings > Features
Added .cursorignore to exclude large directories
Set search.followSymlinks: false
Set files.watcherExclude for large directories
Developer: Reload Window after each change
Steps to Reproduce
Open a large C++ project (~18,000 files, ~9.6 GB, includes third_party dependencies with ~14,000 header files)
Use Cmd+Shift+F to search any keyword (e.g. “ABC”)
Observe the slow response
Open the same project in VSCode and perform the same search — results appear instantly
Thanks for the detailed investigation – isolating the bottleneck to Cursor’s search processing layer (rather than ripgrep itself) is really helpful.
You’re right that Cursor runs more extension host processes than VSCode, which adds overhead. We’ve recently shipped several search performance improvements, including fixes for duplicate ripgrep process spawning and a search cache memory leak. Some of these may not have made it into 3.1.14.
One thing to try -
Open Process Explorer (Cmd+Shift+P > “Developer: Open Process Explorer”) and check whether any specific process (especially extension hosts) is consuming unexpected CPU or memory during a search. If you can share the output, that would help us narrow the bottleneck further
Since you mentioned this started after a recent upgrade, could you confirm whether the same project searched normally in the previous Cursor version you were on?
We’re tracking this and appreciate the report – your ripgrep timing data is exactly the kind of evidence that helps our Client Infra team pinpoint these issues.
Also, today I switched back to Cursor 2.6 and found that the search is still very slow. I previously thought it was fast, but that was probably because I had a different project open.
Had to patch it with a .ignore file to exclude some folders — still much slower than VSCode. Why does Cursor even touch Cmd+Shift+F results? Disappointing.
I’m seeing the same issue on my machine as well.
In my case, this does not appear to be caused by ripgrep itself or by missing exclude rules. I checked the actual project and Cursor settings in detail:
The workspace is large overall, around 8.4 GB and ~470k files.
However, with normal ignore/exclude rules applied, ripgrep only sees around ~10k searchable files.
node_modules, .pnpm, .cache, dist, coverage, .turbo, and log files are excluded.
“Use Exclude Settings and Ignore Files” is enabled in the Search panel.
Cursor’s logs show that these exclude rules are indeed being passed to ripgrep.
Running Cursor’s bundled ripgrep directly from the terminal on the same workspace is fast, usually under 1 second for the same queries.
But the same global search from Cursor’s UI can still be very slow.
I also tested the same project in VS Code and other similar editors/tools, and they do not have this issue. The slowdown only happens in Cursor.
Based on this, it looks like the bottleneck is somewhere in Cursor’s search orchestration, extension host, result processing, or UI rendering layer, rather than in the underlying ripgrep command or the project’s exclude configuration.
This is a very disruptive issue for daily use, especially in larger monorepos. Global search is one of the most frequently used editor features, so having it much slower than VS Code on the exact same project makes Cursor significantly harder to use.
I hope the Cursor team can prioritize investigating and fixing this soon. I’m happy to provide logs or additional diagnostics if helpful.
@Luke2 - I tried reproducing this on a large workspace (14 GB) and global search completed in roughly the same timeframe as running ripgrep directly from the terminal. So the bottleneck may depend on specific project characteristics (file types, result density, or workspace layout) that we haven’t replicated yet.
To help us reproduce on our end, could you share a few details?
Process Explorer during active search: Open Cmd+Shift+P > “Developer: Open Process Explorer”, then run a slow search and screenshot it while results are streaming in (not after they finish). This shows which process spikes.
A sample search term and rough timing: What term are you searching, how many results does it return, and roughly how long does it take?
Whether using “Files to Include” filters changes the speed — e.g., restricting to *.ts or a specific subfolder.
@marszuo Same question: are you still seeing this? A Process Explorer capture during an active search would be the most helpful next step. Your earlier screenshot was at idle, which looked normal.
