Visual Studio 2012 winform designer is VERY slow

Question

We've recently migrated one of our Winforms projects to Visual Studio 2012 from Visual Studio 2008. The transition has went remarkably smoothly and everything builds just fine, however we're now struggling with the winforms designer, which is running incredibly slow.

To give an example, if we open a small form (the form contains two text boxes, a numeric updown and two buttons - all standard built-in controls, nothing 3rd party), it will take approximately 40-45 seconds in 2012, however on 2008 it would open in 1 or 2 seconds. For our larger forms, this difference is much more pronounced. In 2008, it would take about 7 seconds to open the form but in 2012 its taking over 6 minutes. The worst part is that this is a blocking action, VS2012 is almost completely unresponsive while opening the forms. This also happens just by clicking on the .h of a form, so it's not like we can easily avoid it just by sticking to the code itself.

Has anyone else experienced this? Does anyone know why it's happening and if there's anything that can be done about it?

Additional information: Our application is a C++/CLI winforms app. The behaviour is seen on all of our development machines, which run Windows 7 x64. My machine is a Core i7 860 CPU with 12Gb of RAM (over 60% free right now while I was benchmarking the above) - more than enough, I would think. In any case, my system is by no means running slow, it's just the VS2012 designer.

EDIT: Just for extra clarification, we haven't installed ANY addons or anything like that. This is a virgin VS2012 install.

EDIT2: It doesn't seem to be a network thing, either.

Answer 1

I don't know the cause of the delay, but I can tell you a way to determine the cause. Use another instance of Visual Studio to debug it. Attach to the devenv.exe process: Debugging Visual Studio

If you break all threads once in a while, during the delay, statistically speaking, you are likely to find a stack that contains the calls causing the delay. This is a "poor man's profiler," but it works very well. I have used this technique previously to discover and report regressive performance changes in the Visual Studio 2010 designer code generator (which were not fixed by Microsoft).