Home Dashboard Directory Help
Search

"Go to definition" is occasionally extremely slow by Hendrik Wagenaar


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


9
0
Sign in
to vote
Type: Bug
ID: 569225
Opened: 6/21/2010 6:20:32 AM
Access Restriction: Public
0
Workaround(s)
view
4
User(s) can reproduce this bug

Description

I have a large makefile project with over 24000 files, mostly .cpp and .h files. There are some .cs, .xslt, makefiles, etc.

The performance of "Go to definition" is extremely slow at times. It normally only takes a few seconds (still slower than 2008) to find the definition, but often it takes over two minutes.

Some things to note:
1. when the problem happens, I've already let Visual studio build it's intellisense data and parse headers
2. The performance seems to depends on what the type is.
3. The second time I use go to definition on the same type it will only take a few seconds instead of a couple of minutes, so it is caching stuff.
4. It blocks, I can't continue editing code.

When the problem happens, I could do a manual search for the definition faster than go to definition, which always leaves me guessing if I should use the feature or not (and since a manual search does not block, I can continue working while searching).

Since we build outside of the IDE, "go to definition" is the main reason I build a project. I have several colleagues who have moved back to 2008 since "go to definition" performs much better there (although it has its own problems).

I'm on a 4 core i7, 6 gigs of ram, 64bit win7.

I have dump files for "go to definition" which took over 5 seconds
Details
Sign in to post a comment.
Posted by Vincent Huffaker on 4/4/2011 at 1:37 PM
I experience this same problem. VS2010 both original and SP1, with no difference. I only have 7 projects, about 800 cpp files, and it often takes 15-20 seconds to get "Go To Definition" to work. It should be instantaneous. You can look on my PC if it would help. I have win7-pro-x64, 8gb ram, intel ssd, and new intel core i7-2620. VS2010 *should* be quite speedy.
Posted by Hendrik Wagenaar on 4/4/2011 at 7:35 AM
Hi RD Holland,

>> Try using this on an industrial sized application with tens of millions of lines
The application I work on has over 20 million lines :)

Have you tried out sp1 yet? Huge improvement. They've added a cancel button, and the goto def seems much faster. It's still slow every once in a while, but most (90%) of my goto defs are under 3 seconds now (I cancel the rest and regex index search now).

If you're working on a makefile project, make sure your NMake settings have all of your preprocessor definitions.

"Include Search Path": is part of the problem. It's needed for every folder where "-I" is used in the make flags. But the more folders you add to VS, the slower intellisense becomes, and the less you add, the slower intellisense becomes. Fortunately for us, 90% of our headers have 3 root directories, and by placing these 3 include roots first (as Andy explained to me, order matters here), 90% of our headers are found quickly by intellisense.

Splitting the "Include Search Paths" up per module/project doesn't help, since intellisense unfortunately works on the whole solution.

We purposely left out many folders to keep the speed up.

There is one solution -- not easy for a project of your or my size -- try to make as many of the includes have a common root as possible, this way you cut down on the number of "-I"'s.
Posted by RD Holland on 3/30/2011 at 8:07 AM
How about a cancel button? Often I just use the task manager to kill VS 2010. This guy is lucky when it only takes him 2 minutes. But he has a small application. Try using this on an industrial sized application with tens of millions of lines of code and four or finve hundred DLLs (plus the mfc and windows and .net dlls).

Most of the time when I am searching for a symbol it is in the project I am in. But I have to sit as intellisense tells me it is searching mfc files and other files (and we have tens of thousands of files when you count our files, mfc, windows sdk, sharepoint sdk and third party sdks). Yesterday I killed VS after I broke into _wcsimp because I got a (handled) exception I wanted more info on. I saw "EINVAL" and "_NLSCMPERROR" and wanted to find out what their values were to try and correlate that to the exception code the debugger said it encountered. Big mistake!

So how about when intellisense finds a definition of a symbol, it immediately shows that results and lets me continue the search if it is not what I am looking for. And a "cancel" button instead of "visual studio is busy" would be very very handy when I make a mistake like looking for "EINVAL" or "_NLSCMPERROR".

Oh, and all these cores on my mahcine - are they being used? Often while I am waiting and waiting I goto task manager to see the performance and I see "5%" cpu utilization. Can't VS thread off some of the processing? It seems the intellisense may be loading up all the files in a single thread and when that is done processing of the data starts. At least use one of the other cores to allow me to click a cancel button!
Posted by Microsoft on 7/19/2010 at 5:46 PM
Hi -

Thanks for filing this issue. We are aware of some slowdowns related to gotodef (and intellisense in general). Most intellisense issues that we find deal with iPCH not being created successfully, resulting in the intellisense compiler being very slow to compile. This is less of a problem for the current source file (since it is background compiled), but gotodef also queries intellisense from other files, and it is the compilation of these files that is often slow.

What you should look for is errors in the PCH for the file that is the target of the gotodef (where gotodef eventually ends up), as this is most likely the file that is compiling slowly. You should ensure that PCH is turned on for this file and that the error list window is free of errors.

Because it appears you are using a makefile project, you may need to set PCH, Include, or compiler define options for intellisense seperately from your build compilation in order to reduce or remove intellisense errors. (Right click, go to properties, and choose Configuration Properties->NMake. There is an "intellisense" subsection in here for options specific to the intellisense compiler.

We are looking to mitigate this in SP1 by making errors in the PCH not prevent compilation, but at the current time, there is no other good workaround for your problems, other than attempting to remove these errors.

Since there is no specific bug that we can get from the traces provided, and the likelihood that the root issue is the PCH one, I am going to close this bug as "Not Reproducible." We are tracking the PCH mitigation issue in another bug.

If you would like more assistance in diagnosing your issue, you can contact me directly at arich [at] microsoft [dot] com.

Thank you for filing this issue.

Andy Rich,
Visual C++ QA
Posted by Hendrik Wagenaar on 6/29/2010 at 5:35 AM
To clarify, the 3 dumps were obtained on different days, they are not all from the same goto definition, although creating several dumps of the same goto definition might be helpful... maybe I'll try this later.
Posted by Hendrik Wagenaar on 6/29/2010 at 5:33 AM
Hi, I've attached "Feedback.569225.zip" which contains 3 dump files obtained at various points of a slow "goto definition". Hopefully you can gather some useful info from these.
Posted by Microsoft on 6/23/2010 at 11:15 AM
Dear Hendrik,
you mention you have dump files, we have a secure site where you can upload your thesefiles. Please include part of your name or issue in the file names, something like “Hendrick.GotoDef” or “Feedback.569225”, this really helps us identify the files. Also, if files are large, please zip the files before uploading, this will reduce your upload time.
Workspace URL: (https://sftus.one.microsoft.com/choosetransfer.aspx?key=e47c0d1e-aeed-4ba4-9dcd-886dc4b574aa )
Passwd: wBy{e@!x$-]{j2t
Thank you,
VS Platform Team

Posted by Microsoft on 6/22/2010 at 1:09 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Sign in to post a workaround.