Visual Studio debuggin perfromance Improvement.
Solution
Improving Visual studio debugging performance.
1. Disable Intellitrace completely
2. Tools -> Options -> IntelliTrace -> [ ] Enable IntelliTrace
3. Delete all the Visual studio breakpoints
a. You may need to delete all your breakpoints---note that you need to click the "delete all breakpoints" button (or use Ctrl-Shft-F9), NOT just delete them one by one. If Visual Studio has mangled your solution settings the latter will not work. You may need to add a breakpoint first, in order for this to work (clever, eh?)
i. If worst comes to worst, you may need to delete your .suo file and let Visual Studio start a new one from scratch. Note that you will lose your personal solution configuration settings, however (only for this solution, not any others). However, you may want to move/rename the file temporarily until you determine whether or not this is the problem; that way, you can always move it back. I have seen some online resources recommend deleting (moving/renaming) the .ncb file as well.
4. I just noticed that you mentioned setting up .NET source debugging feature. Try to disable that, your network connectivity to Microsoft's source server may be slow. Also disable any symbol server connectivity in Tools > Options > Debugging > Symbols
5. Also try disabling "Enable property evaluation and other implicit function calls" in Tools > Options > Debugging > General.
6. Make sure you don't have any stale network mappings to servers that no longer exist (network timeouts will kill you). Or use something like Process Monitor to see if a network (or other file error) seems to be blocking for a long time.
7. Go to tools/options/debugger/symbols and check if you have public symbols set or UNC network paths set. Also check tools/options/debugger/general to see if you have source server set.
8. All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
9. If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
10. Go to tools/options/debugger/symbols and check if you have public symbols set or UNC network paths set. Also check tools/options/debugger/general to see if you have source server set.
11. All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
12. If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
13. I've found that if I've had a seperate IE window open for a long time it can take up to a minute to start debugging. Close all IE windows and debugging starts immediately.
14. simply restarting visual studio and only opening one instance of visual studio at a time
15. Get more memory and a faster HD. More details here.
16. By caching the debugging symbol load.
In order to dramatically improve your debugging you need to have Visual Studio use a cached version of the symbol files, as well as ensure its not trying to locate symbol files on slow network shares.
Here are the steps you need to fix the issue:
1. Create a directory to store you locally cached symbols. Ie C:\Temp\SymbolCache
2. Change the debug settings for loading symbols, via Tools
Options
Debugging
Symbols.
3. (Option 1) Start debugging the code you want (on a machine that can access the internet; even if its slow) and have it sit on a break point. Then go back to the Symbols settings, where you’ll notice the button Load symbols from Microsoft symbol servers is now active (because that was obvious!). Click the button and you’ll see a popup windows indicating the download of the symbol files. After this is complete you can close out of this window and stop debugging. If you now check your Symbol Cache directory you’ll see you have a load of downloaded symbols (may vary depending on what you’ve referenced).
4. (Option 2) If you have already done option 1 and you need to apply this to another machine, such as a team members machine, you can simply copy the files from one machine to the other.
5. Depending on your environment you may also have one of two environment variables that need updating. Set either of these environment variables to the same location as the cache created in setup 2. The environment variables to change are _NT_SYMBOL_PATH or _NT_ALT_SYMBOL_PATH. The default setting for these are pointing to the Microsoft Symbols server. You can access the variables either via DOS (set command) or via the Advanced System Properties dialog in Windows.
One you’ve completed the changes you should see a dramatic improvement in your performance. Remember to check in Step 2 that you don’t have any non-existent paths or UNC paths defined as this will also slow things down.
Improving Visual studio debugging performance.
1. Disable Intellitrace completely
2. Tools -> Options -> IntelliTrace -> [ ] Enable IntelliTrace
3. Delete all the Visual studio breakpoints
a. You may need to delete all your breakpoints---note that you need to click the "delete all breakpoints" button (or use Ctrl-Shft-F9), NOT just delete them one by one. If Visual Studio has mangled your solution settings the latter will not work. You may need to add a breakpoint first, in order for this to work (clever, eh?)
i. If worst comes to worst, you may need to delete your .suo file and let Visual Studio start a new one from scratch. Note that you will lose your personal solution configuration settings, however (only for this solution, not any others). However, you may want to move/rename the file temporarily until you determine whether or not this is the problem; that way, you can always move it back. I have seen some online resources recommend deleting (moving/renaming) the .ncb file as well.
4. I just noticed that you mentioned setting up .NET source debugging feature. Try to disable that, your network connectivity to Microsoft's source server may be slow. Also disable any symbol server connectivity in Tools > Options > Debugging > Symbols
5. Also try disabling "Enable property evaluation and other implicit function calls" in Tools > Options > Debugging > General.
6. Make sure you don't have any stale network mappings to servers that no longer exist (network timeouts will kill you). Or use something like Process Monitor to see if a network (or other file error) seems to be blocking for a long time.
7. Go to tools/options/debugger/symbols and check if you have public symbols set or UNC network paths set. Also check tools/options/debugger/general to see if you have source server set.
8. All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
9. If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
10. Go to tools/options/debugger/symbols and check if you have public symbols set or UNC network paths set. Also check tools/options/debugger/general to see if you have source server set.
11. All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
12. If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
13. I've found that if I've had a seperate IE window open for a long time it can take up to a minute to start debugging. Close all IE windows and debugging starts immediately.
14. simply restarting visual studio and only opening one instance of visual studio at a time
15. Get more memory and a faster HD. More details here.
16. By caching the debugging symbol load.
In order to dramatically improve your debugging you need to have Visual Studio use a cached version of the symbol files, as well as ensure its not trying to locate symbol files on slow network shares.
Here are the steps you need to fix the issue:
1. Create a directory to store you locally cached symbols. Ie C:\Temp\SymbolCache
2. Change the debug settings for loading symbols, via Tools
Options
Debugging
Symbols.
3. (Option 1) Start debugging the code you want (on a machine that can access the internet; even if its slow) and have it sit on a break point. Then go back to the Symbols settings, where you’ll notice the button Load symbols from Microsoft symbol servers is now active (because that was obvious!). Click the button and you’ll see a popup windows indicating the download of the symbol files. After this is complete you can close out of this window and stop debugging. If you now check your Symbol Cache directory you’ll see you have a load of downloaded symbols (may vary depending on what you’ve referenced).
4. (Option 2) If you have already done option 1 and you need to apply this to another machine, such as a team members machine, you can simply copy the files from one machine to the other.
5. Depending on your environment you may also have one of two environment variables that need updating. Set either of these environment variables to the same location as the cache created in setup 2. The environment variables to change are _NT_SYMBOL_PATH or _NT_ALT_SYMBOL_PATH. The default setting for these are pointing to the Microsoft Symbols server. You can access the variables either via DOS (set command) or via the Advanced System Properties dialog in Windows.
One you’ve completed the changes you should see a dramatic improvement in your performance. Remember to check in Step 2 that you don’t have any non-existent paths or UNC paths defined as this will also slow things down.
Comments
Please dont disable it.
5. Also try disabling "Enable property evaluation and other implicit function calls" in Tools > Options > Debugging > General.
Enable it back if you need debuggin details.