This post is part of my PDC09 Conference Notes series. These are my raw notes taken while watching the various session videos from PDC09. Refer to my original post for some conventions I tried to use.

PDC Session Link: Advanced WPF Application Performance Tuning and Analysis

This presentation was how you can analyze and tune your WPF applications in 4 key areas: Memory Usage, Cold Startup Time, Warm Startup Time, and Runtime. There were several tools used through out the presentation, and the demos were very well done. I would recommend watching this session to get a better feel for the concepts. The sample application used for the session is called Fishbowl, and is a WPF application that lets you work with Facebook in new ways.

Introduction

• Measure early and measure often
• Be sure to test on older hardware
• Grab low hanging fruit
• Understand perceived performance (i.e. keep the UI responsive during long running requests)
• Trade Offs
• CPU vs. Memory vs. Disk IO
• Within your application, you may have to pick and choose which features are faster then others

Memory Usage

• 150MB of memory was deemed as high for an application like Fishbowl
• I found this to be very surprising given how many seemingly simple WPF apps I have seen using over 200mb of memory at startup. Is memory cheap these days? Yes, unless you count limited memory on Netbooks, older computers, and virtual machines.
• Process Explorer to view overall memory usage
• Sys-internals VMap to view detailed memory usage by process
• Image: .exe, .dll, etc
• Heap: Pure managed applications should have lower native heap then managed heap. You will always have some native heap, as some CLR stuff uses native memory, like the render thread. Images (pictures) are also stored in the native heap and are one source of high native heap usage.
• Managed:
• The cause of the high memory usage was the use of 114 images for the startup animation.
• # of images * width in pixles * hieght in pixles * 4 (32 bit color) = memory usage
• 114 * 272 * 294 * 4 = 34.7MB
• The actual cause turned out to be that the start view was not being disposed after it was finished, so the images remained in memory.
• SaciTech Memory Profiler on memProfiler.com
• Costs money
• WPF perf team uses this tool internally
• Lets you do snapshots so you can compare memory usage over time
• You can drill down by object type, as well as what is holding onto the reference for a particular object.
• Element count (virtualization) is another pain point

Cold Start

• Cold start is impacting most by Disk IO
• Windows Performance Tool Kit or Windows SDK?
• xperf command line tool (there is a PDC session on xpef and ETW)
• Event Tracing for windows (ETW): Add ETW statements to your app and profile with xperf
• Demo showed a batch file to start up xperf
• Look for for highest number of reads
• Remove unneeded dll references
• System.Windows.Forms and System.Windows.Drawing shouldn’t be needed in pure WPF application
• If you are using only one or two methods from a dll, you could merge it into your application
• You can use Scitech Mem Profiler to see how many types for dll to see you can eliminate or merge
• If you are using a managed API that is dealing with win32 api’s, you could add p/Inovke’s to your code to eliminate an extra dll.
• Be sure to test in release mode with no debuggers attached
• You can use NGen to speed up cold start, but it might slow down warm start

Warm Start

• Warm Start is CPU bound, so you will see high CPU usage. There should also be lower disk IO then cold start.
• If you see low CPU usage, there might be something blocking, like network access (using xperf again)
• CPU Profiler
• Comes with Team Suite
• WPF Perf
• Part of Windows Performance tool kit
• Check item count, is virtualization enabled. Sometimes virtualization can’t be used, like when list element height is dynamic, which would screw up the scroll bar

Runtime

• More WPF Perf usage
• Trouble shoot jerky animations
• Layout vs. Rendering
• Pererator Tool:
• Review hardware IRT’s. In the example, 20 hardware IRTs was too high.
• Problem was traced to drop shadow animation. Solution was to create two elements, one with and one without drop shadow, then toggle visibility
• Other stuff
• Don’t block on the UI thread
• Virtualization when needed
• Freeze your freezables
• No change notification call backs
• Hardware vs. Software
• use RenderCapabilities.Tier to determine when you should dial down visual effects.

This post is part of my PDC09 Conference Notes series. These are my raw notes taken while watching the various session videos from PDC09. Refer to my original post for some conventions I tried to use.

PDC Link: Advanced Topics for Building Large-Scale Applications with Microsoft Silverlight
Presenter: John Papa (@john_papa)

The title of this presentation is a little misleading. It could have just as easily been titled, best practices for building line of business applications in SilverLight. The concepts, if not most of the code can be applied to WPF as well. There was a lot of talk about Prism, which I have not looked at in great detail. However, as a result of this presentation, I will take a closer look at it once I get around to working with SilverLight and WPF more. John pointed out several times that you are able to pick and choose what parts of Prism you want to use, which at least makes it sound a little less invasive then some of the other things to come out of Patterns and Practice.

A similar framework which is not developed by Microsoft is Caliburn. Which one is better, is probably open to debate, and both are continued to be developed. John did mention some gaps in Prism, which he developed some code for (posted via his blog), but perhaps these are available in Caliburn. If you are just starting out with SilverLight or WPF, I would suggest looking at both frameworks. If you are already using one or the other, I don’t know how much sense it would make to switch, but I always like to keep my options open.

MVVM

The first part of the presentation was focused on defining MVVM, or the Model, View, View-Model pattern. The primary benefit of the MVVM pattern, is that is allows for good separation of concerns, which leads to increased testability and maintainability. As you can see below, a lot of time was spent on describing the View-Model and how it fits in, while the View and Model are fairly straight forward.

• View: Responsible for rendering the UI only
• Model: Contains your domain entities (i.e. customer, order and order details)
• View-Model:
  • Handles the communication between your View and Model thru bindings, commands, events.
  • Responsible for providing everything (data) a particular view requires.
  • Sometimes your View-Model will look almost identical to your model. Other times, it will contain a mash-up of various entities as required by the view.
  • Ensures that your view knows nothing about your model, and that your model doesn’t known anything about the view (or require references to view related dependencies)

Three ways to implement MVVM were presented. I had never considered the first two, while the 3rd one is where frameworks like Prism, Caliburn, Ninject (Inversion of control) come into play.

• ViewFirst (Static Resource): View Model can be created as a static resource in the view. This tightly couples the View Model to the view, but gives you the best experience when using Blend (referred to as blenability)
• ViewFirst (Code Behind): The view is injected to the View Model constructor. Since you loose the blendability, I’m not sure why you would pick this over option 3.
• View + View Model Marrige: Use a intermediary to marry the View and the View-Model together. Again, you loose blendability, but this is the approach that everyone takes when using Prism, Caliburn or a home grown framework.

When creating a SilverLight application using MVVM, there are some common functionality that you need to implement, which is where Prism and Caliburn come into play. Since this session used Prism, I will list what was shown, which was limited to what Prism can offer. I expect that Caliburn offers a similar set of functionality.

• Shell: Container for all UI modules, such as menus, windows etc.
• Regions: Shell is made up of regions which control where UI modules are displayed.
• Modules: Separate code modules that can be developed in isolation and then loaded by Prism. Modules can talk to one another thru event aggregation (I wonder if MEF would be a better choice)
• Event Aggregation: An eventing model that allows for cross module communication.
• Commands: SilverLight 4 adds support for commands, so it is my understanding you do not need to use Prism’s command support anymore.
• Bootstrapper: Controls application startup and configuration. Configure your IoC here.
• Delegate Command object for use with commands (very simple class to create if you are not using Prism)

Commands:

• Invoke an event on your view and have your view model respond to it.
• When you invoke a command, you expect a response.
• Commands work out of the box well with buttons. However you need to create new command objects that implement ICommand for use with other controls. John puts these objects in his Infrastructure dll, and I think he may have provided some of this code on his blog.
• I still have a lot to learn on commanding

Well it’s not exactly my first, but might as well be. Aside from playing around with WPF a couple of times, I’ve never really sat down and written an application from start to finish. Hopefully, this will be one time where I do finish.

Given a set of requirements that contains a series of screens, I am to implement a wizard like interface. Since this application is targeting external customers, looks will count for something. I also want to make sure that there is no confusion between the old application and this new version of the application.

To start with, I have installed Expression Studio 3, along with the WPF themes from the WPF toolkit. The themes are part of the WPF futures release in the WPF toolkit project on CodePlex. I then created a new WPF application in Visual Studio (since I was waiting for Expression to download and install) and added the Expression dark theme to my App.Xaml file as a resource dictionary (key section is in bold below). You can see in the source attribute, that I have added themes folder that will contain all of the downloaded themes. I then switched to Expression Blend 3 to begin work on the UI in earnest.

<Application x:Class="ThemesSample.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    StartupUri="Window1.xaml">
    <Application.Resources>
        <ResourceDictionary Source="Themes\ExpressionDark.xaml"/>
    </Application.Resources>
</Application>

As I am a firm believer in not re-inventing a wheel, a quick Bing search gave me some possible WPF wizard implementations. There were a couple of pay options, and one open source option,  Piotr Wlodek’s WPF Wizard Control. His sample application and code looked pretty straight forward and I was fairly certain I could massage it into my application without too many problems.

After downloading and extracting the WPF Wizard Control, I was presented with three projects. Pitor’s post uses the code in the WPF Wizard 2 project, so I started there as well. The base control is named Wizard and is in the controls folder. So I created a controls folder in my project as well, and imported Wizard.cs by using the Add Existing Item option in Blend and updated the namespace to match my project.

Next I deleted the MainWindow.xaml file that was created with my new project, and imported the Window1.xaml from the WPF Wizard 2 project. Again, I had to go thru and update the namespace in the code behind file, as well as change the class name in Window1.xaml from WpfWizard to MyNamingConvention.Window1. You will also need to update the reference to Controls on line 4 in Window1.xaml to match your namespace. Once finished, you should be able to build, and see an empty white window in the designer for Window1.

So where is the Wizard? Well, the original project uses a Generic.Xaml file to define the styles of the various UI elements. Since we haven't imported that yet, we don’t see anything. The problem that we need to solve is “merging” the Generic.xaml from the Wpf Wizard project with our themes that we downloaded. I wanted to show you what the application looked like at this point, because I think it shows how WPF operates differently from other types of applications.

In order to have a good starting point, I went ahead and imported the Generic.xaml file from the Wpf Wizard project, and updated the namespace on line 3. After rebuilding, I now start to see some actual UI elements on Window1. You should also note that the check box on the side bar is in fact picking up our ExpressionDark theme. However, the buttons are not picking up the theme, and the background is certainly not appropriate for our ExpressDark theme.

To fix the buttons, I went ahead and removed the style property for each button in Generic.xml, and manually set the margins and width on each button. This allows the buttons to pick up the style from ExpressionDark. There is a way to do some style inheritance, but at this point I don’t think I need it for the buttons. However, you can add the following attribute to the a style tag: BasedOn="{StaticResource {x:Type Button}}” – See this post for more information on the BasedOn attribute.

The background color for the wizard was really giving me problems, so I decided to skip it for now and add the rest of the my wizard pages so I could test that out. Switching back to Window1.xaml (view XAML), you will see that the wizard is made up of a Wizard control tag, and then 1 or more WizardPage child controls (see image below). The hierarchy is:

• Wizard
  • WizardPage (CanFinish, CanCancel)
    • SideHeader: Option. I’m using it to show progress thru the Wizard
    • Border: Main content and additional controls go here

I created my first page, complete with a stack panel in the SideHeader, which contains 6 labels to indicate which step of the Wizard we are on. I then copied and pasted the <WizardPage> 5 times, changed the comment before each page, and updated the label names to get my basic 6 screen wizard. The CanCancel attribute on the Wizard page is set to true by default, so I left that as is, and since I only want someone to be able to finish after getting to the last screen, I set CanFinish to true on the 6th <WizardPage>.

I went back to the background color and finally figured out that you need to change the styles defined in Window1.xaml, not Generic.xaml for:

• x:Key="{x:Static Controls:Wizard.HeaderPanelBorderResourceKey}"
• x:Key="{x:Static Controls:Wizard.SideHeaderPanelBorderResourceKey}"
• x:Key="{x:Static Controls:Wizard.NavigationPanelBorderResourceKey}"
• x:Key="{x:Static Controls:Wizard.ContentPanelBorderResourceKey}"

I’m going to assume that since the styles were defined in two locations, the one in Window1.xaml takes precedence. The styles in Generic.xaml are either there as defaults, or were unintentionally left there by the original author.

My final touch, was to define a second style for my ProgressLabels, called ProgressLabelSelected, which changes the foreground color. When not selected the label is black, when selected the label is white. Here is what Window1.xaml now looks for me after the background and label changes, and I think it’s coming along nicely.

One thing that I do not like about this wizard control, but is present in almost any wizard control I have used, is that it’s difficult to work with the various wizard screens. While you can edit the xaml directly, that is kind of a pain and gives no design time view. Hiding the WizardPage doesn’t work, and so far my only option is to drag the wizard page I want to work with to the top of the list.

I think I’m at a good spot to leave off at for this post as I move onto adding more controls and content to the various Wizard Pages. I’ll come back with a second post on what I learn during that process.