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.

Pleiad

Delays of 40+ seconds are networking delays. The default timeout on a tcp connection attempt is 45 seconds. Use a tcp/ip sniffer to find out what it is trying to connect to. – Aspectual

To rule out network traffic you can pull the ethernet plug. – Zollie

I've done some preliminary tests to rule out networking being a factor. I couldn't just remove the Ethernet cable as I have multiple virtual adapters on my machine (thanks to VMware) so I just disabled them all. I ran a ping test and got an immediate failure to confirm this. There was no change that I could see within VS2012. I also ran Wireshark and although I'm not massively familiar with it, I couldn't spot anything happening specifically when running VS2012. It might take a better man than I to check, though. – Pleiad

Just to keep people up to date....there's been absolutely no change here. I've posted on a few other forums and still nobody has any clue what's causing this and how to help fix it. – Pleiad

Still no answers. Upon talking to a friend, he suggested that perhaps it was slow due to using WPF (and thus being more reliant on the GPU). True enough, the GPU in my work machine was a very low-end geforce (a Geforce 310). I took the project home to my own PC, which has a Geforce 560 Ti in it - drivers up to date and such. Still no change, slower than anything. – Pleiad

Answer 1

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

Pleiad

Answer 2

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

Guilt

Visual Studio uses a lot of threads, and I don't think there's any .pdb's available, which means you're basically hunting a needle in a haystack with this approach. – Rafaelrafaela

There are symbols in .net binaries (unless obsuscated), and you can see parameter names. I have found several bugs for Microsoft this way. For example, connect.microsoft.com/VisualStudio/feedback/details/577372/… . The point is, you are not hunting for a needle. You are going directly to the bottleneck. – Guilt

Thanks Frank, that's somewhat helpful. Unfortunately, I think that might be somewhat beyond my own abilities as I've never debugged anything without the source code handy so it almost certainly would be almost futile trying. I'll give it a go, though, although I'm not really sure how it'll help even if I did somehow find the issue? From what you've said, Microsoft aren't massively keen on actually fixing things. – Pleiad

Answer 3

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.

Parallelism

Answer 4

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.

Vespid

Answer 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.

Tympany

Answer 6

Try changing the compiler settings of your C++ project from /clr:pure to /clr.

Unlike