Tips on troubleshooting Visual Studio Performance issues
Another nice write up from Senior Support Escalation Engineer, Irfan Ahmed on Visual Studio performance.
Visual Studio performance is always a topic in discussion. I was working on a Visual Studio performance issue recently and got to know something which I believe should be shared and hence this blog for you. Hope you will find it useful.
The performance problem I was troubleshooting was that the project was migrated to VS2013 Update 3 recently and it was taking minutes to find all reference of a method and caused Visual Studio to go in “Not responding” Mode. This solution contained 75 projects in total. In similar project sometime it takes time to move from one break point to another. This seems to be related to first part of the issue.
Working on this issue further, process monitor log showed that devenv was accessing a particular file multiple times and this is a pattern for multiple files in the project. Analyzing these files we found that there is partial type defined and that is spread across a lot of files. This is by design that we keep looking into partial types for reference. With big projects and most of the files has partial type causes performance issue in Visual Studio.
The following call stack(snippet) and the process monitor log ( snippet) had observed.
# ChildEBP RetAddr
00 0041bdb0 5aef6292 cslangsvc!NameTable::AddString+0x9f
01 (Inline) -------- cslangsvc!NameTable::AddString+0x9c
02 0041bdf4 5af1b8b0 cslangsvc!NameTable::AddLen+0xad
03 (Inline) -------- cslangsvc!NameManager::AddString+0x10
04 0041bed0 5af1c7b1 cslangsvc!CLexer::ScanToken+0x315
05 0041bf1c 5af1c473 cslangsvc!CSourceData::CTokenizer::ScanTokens+0x48
06 0041bfd4 5af1d51d cslangsvc!CSourceData::CTokenizer::CreateTokenStream+0x3b5
07 0041c0e0 5af1cd86 cslangsvc!CSourceData::CreateTokenStream+0x14d
08 0041c134 5af1cf4b cslangsvc!CSourceData::SetEditInformation+0x9d
09 0041c1ec 5af1cfcc cslangsvc!CSourceModule::ApplyEditsToSourceData+0x159
0a 0041c264 5b00f3ac cslangsvc!CSourceModule::GetSourceData+0xd2
0b 0041c2bc 5b00f311 cslangsvc!CClosedFilesCache::GetSourceSizeInBytes+0x1e
0c 0041c328 5b00e546 cslangsvc!CClosedFilesCache::AddOrReplace+0x96
0d 0041c3a4 5af29523 cslangsvc!CSourceModuleFactory::CClosedFilesCacheSourceModuleGetter::TryGetSourceModule+0x193
0e 0041c3e4 5af2e065 cslangsvc!CSourceModuleFactory::CreateInstance+0x77
0f (Inline) -------- cslangsvc!CSourceModuleFactory::CreateInstance+0x16
There are two workaround suggested to resolve this issue.
- Leave that particular file open in VS. The language service caches the parse tree for files that are open in the editor, which should eliminate the reparsing that you are seeing.
- If it is feasible (code in that project doesn’t change often, etc), remove the project containing this project from the solution, and use a reference to its outputted metadata instead of the project itself.
Written by Irfan Ahmed, Senior Support Escalation Engineer, India/Emea Team
Reviewed by: Rachan Rosario, Escalation Engineer, Languages Team