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.

  1. 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.
  2. 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

 


Comments (0)

Skip to main content