WPF excruciatingly slow in Visual Studio 2008

Question

And apparently single threaded, as only one core is maxing out.  Are there any performance tricks to speed this up?  When I'm editing the xaml, I'm sometimes waiting in excess of a minute to get cursor control back.  This seems to be particularly bad when using a wpf control library.  Any help?  Anyone else having the same issue?

Answer 1

Can you give me the spcifications on your machine?  Processor, Ram and free disk space + operating system.

Thanks!

Ronnie

Answer 2

Core 2 Duo 2.13
2 GB 800 MHz Ram
250 GB HD / 117 GB free
80 GB Swap File Drive w/ 4 GB swap file
XP SP3

Answer 3

I've come across the same problem. After a couple of days of digging I've discovered that wpf usercontrols are created differently by the designer depending on whether you are editing the usercontrol directly, or editing something like the window that contains the user control.

One relevant blog post is available at http://itknowledgeexchange.techtarget.com/wpf/wpf-controls-how-to-avoid-designer-nastiness/

It appears that the designer invokes the constructor for a user controls it renders inside another control such as the main application window. In my case, I think the "(not responding)" title of visual studio 2008 may be caused by data initialization across the user controls, but I'll have to take a closer look at work on Monday. I hope checking for design mode using DesignerProperties.GetIsInDesignMode will fix the slow load times in visual studio.

If this is in fact causing a slowdown in visual studio, I suggest that the team implement some sort of profiling that can tell the developer something along the lines of "Creating The User Control of Type <SomeType> named <Name> took <A long time>" so the developer can fix the problem. It will save developer a lot of frustation with the dev. environment.

Answer 4

I made a simple wpf app to test this.

Create a usercontrol , UserControl1:

1	public TestUserControl1() {
2	InitializeComponent();
3	this.Loaded += new RoutedEventHandler(TestUserControl1_Loaded);
4	}
5
6	void TestUserControl1_Loaded(object sender, RoutedEventArgs e) {
7	Thread.Sleep(10000); // simulate long operation here
8	}
9

I can edit the control just fine on its own. Once I've added it to the main window, and perform a change to the user control that causes the main window designer to require reloading, this locks up visual studio completely for 10 seconds once i reload the designer.

Not exactly a real life scenario, but it proves that initialization code can hang the visual studio gui thread.

Answer 5

 I've been experiencing this with basic test controls.

Answer 6

I've added the check for design time to the user controls in our wpf project. We did have a few places where the initialization code was run at design time, but removing it hardly affected the performance of the xaml editor.

At this point in time, Visual Studio 2008 is borderline unusable for me and the other 5 developers on the project. Editing even the simplest xaml in a users control causes vs to hang for several seconds and become unresponsive. Saving the xaml produces the same problem. I attached tools from sysinternals to analyze what's going on.

From that analysis we found that visual studio spends almost all the cpu time in Microsoft.VisualStudio.Xaml.LanguageService.ni.dll.

Having to wait for visual studio to finish processing even the smallest changes and switching between documents is proving to be a huge source of frustration for us right now. It breaks our workflow and costs us a lot of time each day. There's so much potential in WPF, but we're having a hard time reaching it right now :(

Your response Microsoft?

----

Update:

Specs for our dev machines:

Vista X64 Ultimate SP1
VS 2008 SP1
Intel Core 2 Duo 6400 @ 2.13 GHz
3 GB Ram
64 GB Free disk space

Answer 7

I too am having the same problem, but it's only happening in the project I'm working on now. I hope someone has a fix for this.

Answer 8

I too am having the same problem. I have a project with 30 user controls and 32 windows,
and I get an out of memory exception probably once a day. The main user control that I'm working
on has about 17 user controls on it. My machine's spec is:

Intel Core 2 duo CPU, 2.4ghz
2 gb ram
5.7 gig free on drive c:
XP sp2

Today I got the following message:

error CS0583: Internal Compiler Error (0xc0000005 at address 7C911E58): likely culprit is 'EMITIL'.

which was a first. Normally it's just a basic out of memory exception.

Answer 9

I'm also having this issue. Switching between two user controls (each of them has the designer and the xaml editor part visible). It takes about 3-5 seconds to get cursor control. It appears that this slow down happens also when I move to another application and switch back to Visual Studio - and try to give xaml editor focus. The devenv.exe gets 90% of cpu usage at some moments, and it's constanly at 50% for a few seconds. The user controls have only a windows forms host but the windows forms user control only has a datagridview and in wpf designer it does not show, so why would it be initialized/loaded? In the constructor of the windows forms user control I only set the datasource properties for combobox columns, but even if I remove those lines completely, it's still slow.

I noticed this was happening one or two weeks ago. The project now contains only three windows, about 15 wpf user controls and 40-50 windows forms controls. Recently the number of WPF user control was rising relatively more than windows user controls. What helps a little is restarting Visual Studio.

I have Intel  T2500 2GHz with 3gb ram, vista 32bit sp1, vs2008 sp1

Answer 10

This problem is causing major porblems for me as well.  Just creating a blank WPF C# application, bringing up the Window1.xaml file is extremly slow.  Just moving the cursor with the mouse inside the <Grid> tag takes 5-10 seconds.    I have a fast machine with plenty of RAM.   This problem started for me when I "upgraded" from VS 2008 to VS 2008 SP1 which install .net 3.5 sp1 at the same time. 

Answer 11

After editing XAML in my user control (cutting/pasting a control template and typing new key), devenv.exe pegs my cpu.  I have to kill process.  Has any else experienced this behavior?

Answer 12

I found that after installing the Silverlight 2 SDK, VS 2008 started running extreemly slow when working on WPF projects.

After uninstalling the Silverlight it was all back to normal.

Hopes this helps..

 

Answer 13

Everyone in my project is experiencing the same problem as well.

We are developing a WPF app for .Net 3.5 SP1 and switching between xaml files, moving xaml code, saving, scrolling, and probably some other scenarios also causes VS2008 to lock up for 5 seconds or more for us.

All of us are using dual core workstations of at least 2.2Ghz or higher with 2GB of RAM on on XP 32bit.

Looking through the add/remove programs list I don't see a Silverlight 2 SDK, just the actual Silverlight. We do have Expression Blend 2 installed and it is unaffected by this problem.

Answer 14

Members of my team dread having to open up a xaml file in VS. They feel their productivity draining away and their salaries wasted staring at the hourglass. And that's after fetching a coffee while the 'Toolbox initializing...' process runs its marathon.

Answer 15

We would like to do some performance profiling capture on the machines of customers who are seeing this performance problem with UserControls, to ensure we have it correctly captured.

Please contact me by email at mwthomas at microsoft dot com with the email title "Volunteering for performance profiling on VS2008 WPF designer UserControl issue" if you would like to participate; I will send you a tool for capturing performance data and instructions on how to capture a trace for us to inspect.

Thanks

Mark

---

Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'

Answer 16

It does all the initialization plus any binding that it can find. The designer will in fact try to run the user control code. Not to mention that loading just a user control in design view with 4 or 5 elements is already slow.

I have the feeling this has something to do with a process that already is not optimized like file IO. I tried using our dual xeon-quad core server for kicks, and the design load time didn't improve that much. 

Answer 17

I've participated in the performance profiling project Mark posted above. I encourage everyone to do the same so that improvements can be made!

Answer 18

I have no user controls and yet I am experiencing major slow downs with VS2008 SP1.  It seems that there might be a memory leak somewhere, as the issue builds over time as I'm working on my project.  It's not just XAML windows, though.  As VS slows down, even just returning the focus to the app after, say, browsing the web for some info takes over 30 seconds.  Other apps don't seem to be affected, just VS.  I've not had any related issues with non-WPF projects.

Restarting VS seems to releive the issue for a while.

Just chiming in here...  Waiting for results/answers/fixes...

J

---

http://digitalcamel.blogspot.com - .Net, ILM, SQL and Anything Else That Falls Out Of My Brain

Answer 19

Thanks to all who have volunteered and captured profile information; we will be taking a careful look at this data with a view to improving performance in future releases of Visual Studio.

I should also mention that there is an unrelated issue which can cause Visual Studio 2008 SP1 to hang when working with XAML files - you can tell if you have hit this issue because the Visual Studio symbol will appear in the System Tray area and show Visual Studio as busy for long periods whilst editing your XAML (it may even appear to have hung completely and require a Visual Studio restart using Task Manager). If you are hitting this issue we are in the process of field testing a potential fix and will have more news in a month or so. This is not the performance issue we're looking into here however.

Thanks
Mark

---

Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'

Answer 20

"Future release," so there won't be anymore major enhancements to VS2008?

Answer 21

JRQ - I cannot comment on any future release plans for service packs or other changes to Visual Studio 2008.

I can say that the performance profiles people have supplied are helpful data for the team as we strive to improve the WPF and Silverlight Designer's performance in the next major release of Visual Studio.

Mark

---

Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'

Answer 22

I found that after installing the Silverlight 2 SDK, VS 2008 started running extreemly slow when working on WPF projects.

After uninstalling the Silverlight it was all back to normal.

Hopes this helps..

 

More specifically for me, I had to uninstall the Silverlight Tools for VS 2008.

Answer 23

maybe a late reply but i have the same problem.

I figured out that it happens when you open visual studio 2008 open the project and open a xaml usercontrol or window.
after that it is faster. close the project. Open another project, click through classes is not problem, until you open a xaml usercontrol or window, it does something at the background.

On my machine it takes until a minute before i get the cursor back!
It does not depend on the project size.
a project with just one usercontrol acts the same as a large project...


windows experience index= 5.9
intel quad core 2 q9450  2.67 Ghz
4G memory
Vista ultimate sp2


I forgot to mention:
If visual studio 'hangs' when the xaml is doing something befroe the cursor comes back and I check the task manager. The cpu usage is 0%.
So this would mean that the system is waiting for something??????
Or is visual studio searching my network for something????

Answer 24

I'm having the same issue, but this is not the worst part. I'm getting OutOfMemoryException, whenever working with xaml files, when compiling the project/solution every 7-8-9th time (it's a little inconsistent). This usually requires a restart of VS to get rid of.

I'm usually doing the basic design in Kazaml despite it's limitations (cannot compile events). Often the VS editor cannot display the designer anyway, because of some component not compiling, or because it contains a viewbox. I've found that it's actually worth the while copying the code from the VS editor into Kazaml, removing events and namespace specific stuff, do the modifications, and merge the code back. But this is also very much because editing in the VS designer (if it can show the designer) would require me to restart VS every 15 minutes or so...

// Rasmus

Answer 25

Is there someone of Microsoft who can confirm this???

It's a real pain in the .... when you are working with VS and several projects the whole day.

Answer 26

Sorry for the delayed response - I have been on vacation for a few weeks.

I'd like to dis-entangle several possible problem sources here:

1. Some customers have reported Visual Studio hangs which manifest themselves by the "Visual Studio is Busy" icon in the system tray. These issues are fixed by the KB963035 hotfix; if you have that hotfix installed AND are still seeing the "VS is busy icon" and a VS hang when working with a WPF or Silverlight project please contact me by email at mwthomas at microsoft dot com with the subject line "Still seeing VS hang after installing KB963035"

2. We are looking into a known out of memory issue which some customers are seeing when compiling WPF and Silverlight projects (@Rasmus Sondergard seems to be seeing this issue above). Data on the kind of projects where users are seeing this problem, and memory consumption for devenv.exe on repeated compiles for projects that see the problem, would be very useful, as would a project that reproduces the issue. If you have this sort of data please email me at mwthomas at microsoft dot com with the subject line "VS out of memory issues when compiling WPF projects"

3. Just as with any control, to render it in the desinger we always run code in the constructor of the usercontrol at design time. If that is not what you want, you need to place checks for IsInDesignMode in your constructor code and branch based on design time/run time (see http://blogs.msdn.com/jnak/archive/2006/10/07/Detecting-Design-Mode.aspx for a decent article on how to do this)

Thanks

Mark Wilson-Thomas

---

Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'

Answer 27

2. We are looking into a known out of memory issue which some customers are seeing when compiling WPF and Silverlight projects (@Rasmus Sondergard seems to be seeing this issue above). Data on the kind of projects where users are seeing this problem, and memory consumption for devenv.exe on repeated compiles for projects that see the problem, would be very useful, as would a project that reproduces the issue. If you have this sort of data please email me at mwthomas at microsoft dot com with the subject line "VS out of memory issues when compiling WPF projects"

3. Just as with any control, to render it in the desinger we always run code in the constructor of the usercontrol at design time. If that is not what you want, you need to place checks for IsInDesignMode in your constructor code and branch based on design time/run time (see http://blogs.msdn.com/jnak/archive/2006/10/07/Detecting-Design-Mode.aspx for a decent article on how to do this)

Thanks for your response. I hope you had a nice holiday.

2) I had this also in the past days (1 time). It occures when you are working fast with opening/compiling/close/open other project/etc... At some point i got the out of memory error and the only solution was to close VS and restart it. Looks like it has to do with loading projects and during the load the user is capable of choosing a certain menu item. So the load is not yet finished.

3) If there is code running to build the usercontrol, why is my cpu at 0% ? It can take up to 1 minute I have to wait. 2 of my colleages have the same problem with different projects. I load a project with several references and some usercontrols in this loaded project. Something after opening it works fine, and sometimes it starts waiting for 1 minute. In my opinion there is a VS process waiting for something. Async process that must be completed at the back?

Regards,

Willie.

Answer 28

@Willie007 - have you and your colleagues installed the KB963035 hotfix? It's not clear from your postings whether you have done this. If you have 0 CPU usage, it seems likely that you are hitting the hang issue. Do you see the "VS is busy" systray icon?

Mark

---

Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'

Answer 29

Hi Mark,

I've installed the hotfix and I'm still getting the "is busy" indicator in the systray. I find it comes up most often when the IDE is switching layouts when I stop the debugger.

/John

Answer 30

The hotfix doesn't prevent the is busy indicator completely, but it should prevent it from hanging your machine forcing you to kill devenv using task manager. If you have the hotfix installed and still find you are seeing hangs where the "is busy" indicator is shown and you never get control back, let me know.

Mark

---

Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'

Answer 31

Sorry I should have been clearer. I have to always kill devenv from the task manager whenever this problem occurs. I can still put focus on the window but I'm never able to regain control.

Answer 32

@jippers

Please can you contact me directly by email at mwthomas at microsoft dot com, with subject line "KB963035 doesn't prevent hang when using WPF designer on my box".

---

Mark Wilson-Thomas - Program Team - WPF & SL Designer for Visual Studio - posts are provided 'as-is'

Answer 33

I installed the patch.
the waiting is still there, the only thing i get is when clicking on the project (not responding) in the title bar of the VS project.
I will work with it some time to see if there is a change in the number of occurences.

Answer 34

After working with it some time i found out that it exactly blocks for 1 minute.
2 times i had a time of exactly 2 minutes.

It does not matter which project I load.
So it looks like some process is bound to a 60 seconds wait and if not finished, it wait another minute.............

My projects are stored on a network drive and retrieved by a network mapping.
Copying the main project to the desktop and opening it there has not effect (references lead still to the network map).
We have a 1 Gbit network here. Nothing wireless.

Willie.

Answer 35

Any updates?

Sad to think, the only reason that there hasn't been much outrage over this issue for over a year is probably because almost everyone has already given up on WPF/Silverlight.

Answer 36

Any updates?

Sad to think, the only reason that there hasn't been much outrage over this issue for over a year is probably because almost everyone has already given up on WPF/Silverlight.

Yup... this particular bug makes me want to go back to GDI.

Answer 37

Installing all the fixes proposed after a vs crash also did not work.
As my solution is growing, the wait process is also extending and I am loosing time.


One thing I also find Irritating is that when I have a certain code or xaml window open, the solution explorer does not select the open window.
So when I have a xaml window open, and want to see the code underneight, the item is not selected and I have to search in the solution explorer for the file to open. There are other ways, but this one worked fine until a certain update in the past....