Repository navigation
Improve Find All References performance? #4051
Description
Our testing indicated that performance was on par with Visual Studio and that VS had some bugs that was causing worse performance (due to it getting stuck processing on 1 thread some times) -- Colen Garoutte-Carson (@Colengms) do you know the VS bug that you filed?
But...there's probably stuff we could do to improve performance, but since the bottleneck is generally IntelliSense parsing, I'm not sure yet if the performance gain would be worth the effort.
Generally, the "too long" case will occur if there are too many files to "confirm" -- users could use the cancel or preview if they don't want to wait for confirmation.
Let us know if anyone has a specific repro where you believe we're doing something incorrect (i.e. performance is slower than with VS, similarly configured) that is causing bad performance or too low CPU usage, e.g. if you have a 200k line file somewhere in your code base, it could get "stuck" lexing on 1 core.
The "searching" phase could also take slightly longer (than VS) for opened files because we don't re-use the already opened document object so we have to read it from disk.
Also, let us know if anyone encounters too slow "canceling" or too slow "previewing".
Activity
Colengms commentedon Aug 9, 2019
The VS issue is here: https://developercommunity.visualstudio.com/content/problem/672813/find-all-references-performance-issues.html
harikrishnan94 commentedon Aug 16, 2019
Can "searching" for files containing references be limited to workspace folders, if possible as an option?
Since, IMHO, it may reduce no. of files to be "confirmed". And mostly IMHO, only references within the workspace are required.
jwbecalm commentedon Oct 29, 2021
it's 2021, but find the reference still very slow for c++...
lijh8 commentedon Apr 25, 2022
2022 now
sean-mcmanus commentedon May 4, 2022
ljhm The speed isn't expected to improve by 2023 either, but you could potentially change the settings C_Cpp.references.maxCachedProcesses, C_Cpp.references.maxConcurrentThreads, C_Cpp.references.maxMemory to increase the performance, but whether or not that helps depends on which part of the processing is the bottleneck in the particular invocation and the amount of memory/CPU available.
gtianw commentedon Aug 10, 2022
I miss the speed of Source Insight, which is my development tool before vscode.
😢😢😢2022.08.10😢😢😢
gtianw commentedon Aug 10, 2022
It's fast if the files to confirm are already loaded.
Can we add a command to pre-load all workspace files?
My SSD has enough space.
sean-mcmanus commentedon Aug 11, 2022
gtianw Do you mean to create an IntelliSense process for all the workspace files? You could file a feature request for that. It would use a lot of RAM memory, not SSD, which is disk drive space, which isn't used for memory unless it's paging to the disk.
gtianw commentedon Aug 12, 2022
I mean to create
ipchfor all the workspace files. It use disk drive space.Can't
ipchbe used to speed up?heartacker commentedon Aug 12, 2022
can it be cached in database(hard disk) and we get the result from database inside of cpptools
sean-mcmanus commentedon Aug 12, 2022
gtianw ipch only has info on a headers for a particular TU, so it would already be used to speed up TU creation.
heartacker Yeah, we're aware of the possibility of writing references to the database -- that is being tracked internally (I suppose we could also open a new issue on GitHub). It's a major change though, since our tag parser that writes to the database doesn't currently do a full compile, e.g. of includes/defines, or parse into function definitions.
ODtian commentedon May 3, 2024
Can we pre-process all tag info for a project and store it in a database to boost find reference speed? This database can be generate once and distribute by project, so devs can just download it instead of generate it locally.
bobbrow commentedon May 3, 2024
ODtian We actually already pre-process tag info for the whole project, but with a lexical parser. That approach requires additional symbol confirmation work for find all references which slows it down. Semantic parsing requires a lot of processing time up front and (possibly) a larger database. This is something we're currently investigating.
suchja commentedon Jan 7, 2025
Any news on this one?
Unfortunately I cannot share the repo, but "Find All References" is insanely slow here. Even if only a few files need to be confirmed, it adds several seconds. Sometimes it will confirm 40-50 files which takes at least 30 seconds. There seems to be no difference at all, when I choose preview (nothing is previewed, I still need to await until everything is confirmed).
Not sure how that compares to VS with C++. VS with C# was always really quick.
stefnas commentedon Jan 13, 2025
This is still an issue and a very annoying one, and it's the reason why our R&D department wants to switch to a different IDE.
I love vscode and I don't want to switch, but in a big mulit-language project, the "references" is completely unusable!
truher commentedon May 1, 2026
It does kinda call the question, what was the performance target when this feature was implemented? How bad would it have to be for MS to delete the feature? Almost 7 years later, it's still bad!
heartacker commentedon May 2, 2026
Now I use ctrl + shift + f to find the content, I have abandoned the CPP ref, alas, did not expect vscode to find the text to eat cppref is also reliable.