Vscode-cpptools: Go To Definition/Peek Definiton slow on large codebases

Created on 3 Oct 2016  路  30Comments  路  Source: microsoft/vscode-cpptools

I have tried to use Visual Studio Code CppTools with the Unreal Engine 4 codebase but find it unusable because it takes up to a minute to resolve a "Go To Definition". I can supply my config files if needed.

Language Service bug fixed (release pending) performance

Most helpful comment

The problem still exists on the latest version. Changing the intellisense engine to "Tag Parser", as sean-mcmanus suggested, seems to fix the issue.

I've tested it on libtorrent code base. The default engine not only is very slow (I'm talking minutes here!), but sometimes it just does not work at all and gives me nothing when I try to go to declarations or definitions.

All 30 comments

I got a repro: TEXT in UnrealEngine-release\Engine\Source\Runtime\VulkanRHI\Private\VulkanCommands.cpp . And other "blue" text in that file. It doesn't always repro though.

It seems pretty random: for example - TArray in LegacySlateFontInfoCache.cpp resolves instantly. FScopeLock takes much longer.

I encountered this issue too. I tried go-to-definition on some SoC SDK's codes, and it took around 10 sec to complete the code jumping.

+1 on this issue.
We are a team of 8 developers working with on Angular project and after the project grew the Go to definition has become really really slow sometime. I have an i7 quad core with SSD and 16GB of RAM laptop which is really fast in general...very annoying issue. If this won't be fixed soon we will probably stop using Visual Studio Code - we just lose to much time for this kind of simple operations...

Any advice would be greatly appreciated.

@ssmartin I am not able to repro the original bug with Unreal Engine 4 when using the intelliSenseEngine "Tag Parser", but I'm seeing perf issues with the "Default" intelliSenseEngine. What setting are you using? The problem with Default engine is that the intelliSense processing is single threaded so hover ends up blocking the "Tag Parser" functionality because it runs on the main thread. We should be able to fix the blocking Go to Def via moving the blocking hover calls into separate threads so they don't block the Tag Parser's Go to Def.

+1 on this issue,
go to definition is not working on veryyy large project
on my case it is nodejs project

+1
It's also slow on Android project.

+1
It's also slow on a large web project.

+1
It's also slow on PostgreSQL project

@harikrishnan94 Does it repro when you set the "C_Cpp.intelliSenseEngine" to "Tag Parser"? I suspect the intelliSense client thread may be blocking the main input thread from running the Go to Definition code.

@sean-mcmanus Yeah, when "C_Cpp.intelliSenseEngine" is set to "Tag Parser", Goto definition is working fine. Only when "C_Cpp.intelliSenseEngine" is set to "Default", it is slow. Thanks for clarifying

+1

+1

+1
Slow on a project with about 170 files totaling 1.83 MB. Code base is JS and TS.

Edit: I noticed that setting git.enable to false in the settings for the workspace alleviated this issue. I was also having slowdowns using my build tasks. I followed the suggestion in this thread but that did not fix anything either. I remembered that the last good configuration I had was when I had git disabled, so I reverted back and that fixed it.

+1
Slow on electron project too (takes about 5-10 seconds)

very slow in a medium sized javascript project. the worst part is that it may never find the definition and the progress bar never stops meaning some process is likely pegged at 100% cpu

@aaronryden Our extension only handles Go to Definition for C/C++ files and not javascript files (which are handled by VS Code itself: https://github.com/Microsoft/vscode/issues). Are you experiencing problems with C/C++ files?

sorry, google search fail. please feel free to delete my comment!

It is very slow in a middle c++ project.

A bad feature will lose a client!

+1

ya.. i am facing this issue too..
codebase around 1xxx file

Our implementation was unnecessarily doing a query for all the matching files for each #includes line in a in a file even when the Go to Def was not on a #include line, so our next release will have that fixed, which may fix some of the performance issues...it's hard to tell exactly what performance issue people are hitting without more info -- if there's a red flame in the bottom right, then the performance problem is caused by a different issue which won't be fixed yet (we're tracking that with https://github.com/Microsoft/vscode-cpptools/issues/1928 ). If people are still reproing this (without the red flame) in our next release, we can re-activate this (or people could open a new bug).

0.19.0 has Go to Definition performance improvements (described in my previous comment). If you're still getting performance issues, it could be due to another issue, such as the red flame blocking the go to definition (tracked in https://github.com/Microsoft/vscode-cpptools/issues/1928 ).

+1
using React tried everything including delete all extensions

+++++++++++++++1
using React tried everything including delete all extensions and reinstall VSC, going to use JetBrains products as well, you're lost customer

@muntyanv if you downgrade to the February release (https://code.visualstudio.com/updates/v1_32), I found that this problem no longer exists. This is the second "show-stopping" issue I've found since the March release, so I'm gonna keep the February release until they address some of these issues.

So i got angry cos its basicly impossible to work like that and i have moved to atom..
In the middle of the day i came back to vscode due to no react support in atom and suddenley problem solved.

So meanwhile its working fine.. i dont know how or why but ots looks like its solved.. or at least working for now

Tried like @ambidtech. Downgrading does make it faster

I can confirm as well @ambidtech @muhajirdev

The problem still exists on the latest version. Changing the intellisense engine to "Tag Parser", as sean-mcmanus suggested, seems to fix the issue.

I've tested it on libtorrent code base. The default engine not only is very slow (I'm talking minutes here!), but sometimes it just does not work at all and gives me nothing when I try to go to declarations or definitions.

Was this page helpful?
0 / 5 - 0 ratings