Performance problem (100% CPU) for long time deattaching VS 2010 after debugging an add-in - by Carlos J. Quintero

Status : 

  Deferred<br /><br />
		The product team has reviewed this issue and has deferred it for consideration at a later time.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 588336 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 8/23/2010 4:29:59 AM
Access Restriction Public

Description

When you debug a VS 2010 add-in and you close the second VS 2010 instance (where the add-in is loaded), the first one takes a lot of seconds to return from the debugging mode to the design mode.
Sign in to post a comment.
Posted by Microsoft on 3/7/2011 at 2:00 PM
We aren't seeing this repro on current builds of vNext. Unfortunately we're only taking high-vote Connect issues for SP1 or QFEs. We appreciate the feedback and we'll be interested to see if this repros on vNext once it's released publically.

Thanks,
Visual Studio Platform Team
Posted by Carlos J. Quintero on 2/24/2011 at 10:35 PM
Hello Ryan,

Try in Dev10 because it happens to me every day, I have to click the stop debugging button to avoid the long wait.

About the commandBars["Tools"] performance problem in Dev10, I am aware of it thanks to your posts in the MSDN Forum. I do plan to fix the article in the next days and to blog about it for others to become aware.
Posted by Microsoft on 2/24/2011 at 4:03 PM
Carlos, I can't repro this in Dev11. I will try looking into it in Dev10 and see if there is anything I can figure out. One thing I did notice, this is unrelated to the shutdown stuff but made a BIG difference on the startup perf. The following line:

toolsCommandBar = commandBars[VS_TOOLS_COMMANDBAR_NAME];

is VERY bad perf wise. The problem is you are asking us to locate the Tools menu but doing so from a 'global' context. We have no idea which of the hundreds of toolbars / context menus that comprise our top level collection contain this item. So we check the text for every single top level item (none of them match). We then go back to the first top level item and recursively check ALL of its children for a match. In the case of the tools menu it is near the end of the menu bar, which means we recursively process hundreds (or thousands) of commands before we find the match.

A MUCH better way is to 'scope' your search with the following line instead of the line above:

toolsCommandBar = ((CommandBarPopup)menuCommandBar.Controls[VS_TOOLS_COMMANDBAR_NAME]).CommandBar;

Now we are ONLY looking on the main menu nd we locate the match rather quickly.

In short the more context you can lend to the search the faster and better it will be.

Ryan Molden
Developer
Visual Studio Shell Tea,
Posted by Microsoft on 8/23/2010 at 7:37 PM
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.

Posted by Microsoft on 8/23/2010 at 5:08 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)