Optimizing Infragistics WPF Controls Startup Time

[Infragistics] Kiril Matev / Thursday, July 07, 2011

The XAML platform allows us to deliver controls offering much richer interaction and flexibility when compared against Windows Forms. However, the many complex controls and elaborate themes, can increase the initial start up time in WPF applications, demanding specific attention to ensuring that users don’t have to wait when opening a form. One way to improve initial loading time of forms is to preload complex controls and themes they are using. This approach to improving initial startup time is illustrated in this blog post. If you'd like to learn about XamDataGrid performance optimization in terms of rendering and scrolling speed, please see this post.

The approach consists of opening on a different thread a window containing the components you will be using in your application, which is not shown to the user. The initialization of this window causes the control code to be JIT-ted, theme references to be resolved, and their definitions loaded. Once this CLR housekeeping work is done, subsequent initializations of the pre-loaded controls are significantly faster.

Please download the sample project. Please remember to unblock the ZIP archive before extracting it. The project is built using Visual Studio 2010 and .NET Framework 4. It includes trial versions of the XamDataGrid 11.1 libraries, so you can build and run it without any additional downloads. A fully-functional free 30-day trial of the NetAdvantage for WPF Line of Business product is available. Below are screenshots of the project comparing initialization and rendering times with and without preloading, which illustrates the impact of preloading on initial startup time:


Sample Project UI

Running the sample opens two windows – the preload window, and the main window. The main window displays the amount of time the XamDataGrid window took to initialize and render. It also contains a button, allowing you to launch additional XamDataGrid windows.

How to use this sample

You can see the effect of preloading, by toggling it on and off using the value of the IsPreloaded property, defined in App.xaml.cs. By default it is set to true, causing the hidden window to be initialized and opened at application startup, thus preloading its contents – in this case the XamDataGridXamRibbon and XamDockManager. Set it to false and observe the much longer initial loading time. Click on the button in the form to launch additional windows, containing a XamRibbonXamDockManager and XamDataGrid bound to sample data. The performance benefit is visible in the first invocation, as subsequent invocations use the code JIT-ted during the first invocation.

Please note that in case IsPreloaded is set to false, the first window takes substantially more time to open than any subsequently open grid window. This is because the first time a type is loaded, it has to JIT the MSIL, locate and load theme resources, and so on. This is actually what the hidden preloading window does (when the IsPreloaded property is set to true) – it causes the pre-JIT-ting of MSIL for controls shown int the window, ensuring that when the user actually opens a window containing the same controls, the window will appear much faster, because it can reuse the already JIT-ted code of these controls.

Approach Description

The application opens a window, which isn’t displayed to the user, because it’s shown outside of the bounds of the screen. This window contains controls that will be preloaded, and will subsequently be loaded significantly faster in other screens in the same application. Only controls appearing in the preload window will subsequently have a smaller initial loading time, i.e. unless you preload a component, its initial start up time will not decrease. A significant amount of the initial loading time is due to resolving and loading themes. This is why it's important to have the preload controls theme set to the same theme you'll be using them with in your application. In this sample, the XamDataGridXamRibbon and XamDockManager appear in the preload window, but depending on the controls you are using, you may wish to include them into the preload window, so they can have a smaller initial start up time in your application. Most often, you’d want to preload complex controls such as XamDataGridXamDockManager, XamTilesControl, XamRibbon and XamSchedule.

Preload Window Architectural Implications

This approach only speeds up the first rendering of the preloaded controls. In doing so, it adds to the structural complexity of your application, so you need to carefully consider its implications before adopting it. The preload window is initialized, opened and closed in the OnStartup event handler in App.xaml.cs. You might want to move it together with the rest of your application start-up code (authentication operations to servers, loading presisted data, etc). It uses a separate thread to open the window, in order to minimize the time your system spends initializing. Please consider the implications of the approach for your application before using it.


In this blog post we looked at how to preload complex components in order to improve the initial loading time. For runtime related performance optimizations, please see my blogposts on XamDataGrid performance optimization and XamDataChart real-time data performance optimization. In conjunction with this post, this advice would allow you to present your users with an application featuring complex controls such as XamDataGrid, XamRibbon, XamDockManager that’s not only functional and visually appealing, but also with a short initial loading time.