Visual Studio 2012 winform designer is VERY slow

问题

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.

回答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).

回答2:

I am on Visual Studio 2010 and I experience the same thing. When I am in the Designer and I click on the corresponding .h file or I add another element to the GUI then VS starts to "calculate" the new code for the design and clogs up the CPU completely to a total hang.

My Windows Form contains lots of elements. Over time as I added more and more to the user interface, the switch from the Designer to the code got slower and slower. Currently it takes about 4 minutes (!!!) to switch from the Designer to the code every time I change anything in the design.

As I can see it it can't be a networking problem. It is a more a problem of VS itself which is not able to calculate the code in a fast and efficiently way.

回答3:

I can't offer any guidance on solving this problem. But I can tell you that I have it too. It happens in both Visual Studio 2010 and 2012. I use windows forms with no WPF, so I think the problem is independent of that.

回答4:

Ok, so this question has been open for over a year now and nobody has managed to come up with a concrete answer as to why the winform designer was so slow.

I recently went back to VS2012 and updated to Update 3. Despite pouring over various release notes, I didn't see any mention of performance increases in this area but I'm happy to report that the designer is now much, much faster.

Just to muddy the waters somewhat, my development machine has been upgraded since I originally posted this, I now sport an AMD FX-8350 CPU, 16GB of RAM and an SSD. When I first got this new machine, the first thing I tried was VS2012 and I found that it was just as slow as before. Now it's capable of loading the same form that used to take 6mins+ in about 15s. This is still nearly twice as long as on VS2008, but I can live with that as it's a huge leap from 360s+. I only mention this as I cannot be sure if there has been a bug fixed in the designer, or just performance improvements - perhaps making use of extra processor cores. In other words, your mileage may vary but if you haven't tried it already, try installing Update 3.

You can download Update 3 here: http://www.microsoft.com/en-us/download/details.aspx?id=39305

回答5:

I THOUGHT I was having the same issue, (albeit with VS2013) but perhaps what I've observed may be helpful for others... I'm blaming my upgrade from 32-bit WinXP to 64-bit Win7. Here's why.

Previously I had VS2008 Express on the WinXP machine. The motherboard died so I got a shiny new Windows 7 machine. In comparison, this new machine is blazingly fast with an SSD, twice the memory and a much faster processor.

Initially I installed VS2008, but before I had a chance to work with the forms editor, I realized I would need VS2013 for other reasons. So both versions of Visual Studio are still installed.

Guess what, on my super-fast Windows 7 machine, BOTH versions of visual studio have a very slow forms editor. I have a pretty complex form which I've loaded into both versions of VS. The form is identical with the exception of the fact that one has been ported up to Visual Studio 2013.

This computer is less than 2 weeks old, and I'm confident it's clean of malware.

I also notice that in either version of Visual Studio, when I click on any control in the forms designer, for several seconds during the delay the mouse pointer becomes both a pointer, and a "size" cursor, and both are translucent... which tells me it's alternating the mouse cursor rapidly between the two, so rapidly that they both appear translucent.

My guess is that Windows 7 has a different way of rendering graphics, in particular in the forms editor. (By the way, are we looking at the real controls in the forms editor, or just graphical representations of them? Obviously they don't "work" in the forms editor.)

I tried switching the theme to "Windows classic" (no translucency, square corners, and grey background) which made no noticeable difference.