Some WPF Designer Performance Improvements

Brian Harry

We’ve heard loud and clear that the WPF designer performance in Beta 2 was unacceptable.  Well, in a good kind of way, we knew that before we shipped Beta 2.  This was one case where our performance tests were telling us the right thing.  We discovered some issues late in the Beta 2 cycle (partially a regression, I think) and didn’t have time to fully test a solution to address the performance issues.  We did code it up and include it in the Beta but you have to use a registry key to enable it.  Here’s thread on it if you want to give it a try:

http://social.msdn.microsoft.com/Forums/en-US/vswpfdesigner/thread/4511d43f-c134-4329-a970-e374252a620e

This change will often address slowness and random pauses in the WPF designer.  It’s not the only cause but we’ve found most people who try it see good results.  We’ve since had time to finish it and it is on permanently from here on out.

Today I saw some perfmon graphs that demonstrate how WPF designer overhead is improving over time.

This first graph is from Beta 2 without the reg key flipped.  The very first spike is the CPU hit to open a C# file.  the rest is the CPU hit to open an empty XAML file.

Here’s the state with the reg key flipped.  Don’t be suprised that the reg key didn’t make a huge difference in this scenario.  It makes a much bigger difference in other scenarios.

And here’s the current graph for the same thing with current bits.  As you can see, it continued to improve.

Brian

Brian Harry Corporate Vice President, Cloud Developer Services

Follow