Your opinion matters! Please fill in the InfoQ Survey!

Avoiding Performance Pitfalls With XAML

| by Roopesh Shenoy  Followers on Feb 27, 2012. Estimated reading time: 1 minute |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

The DependencyProperty and DependencyObject which form the building blocks for most XAML features come with a performance cost. An MSDN article “Optimizing C# for XAML Platforms” discusses this in detail along with ways to minimize its impact.

Response Times for accessing and setting DependencyProperty values are a couple of orders of magnitude higher compared to accessing values from CLR Properties. This gets heightened on lower capacity hardware (say a Windows 7 Phone) and when this is done in tight loops or with complex LINQ statements. A few of the solutions that the article suggests -

  • Avoid Dependency properties if the job can be done by CLR Properties
  • Cache the DependencyProperty for gets and compare the new value with existing value before setting (since setting the property to even the same value is just as expensive as setting to a new value). This can either be done in the class having the property, or in case of even in the calling code (say just before iterating in a loop).
  • Consider the complexity of the LINQ query (how many times the query has to iterate through all the items) when deciding whether to use them or just revert to writing loops
  • Avoid lazy initialization when it could lead to more work (like inside a loop)
  • If you are using Panels within ItemControl for realizing multiple items, provide a panel that supports virtualization, such as VirtualizationStackPanel

Two of the most compelling places where we use XAML – in WPF clients for delivering rich client experience/media and in Windows Phone platform that has constrained hardware resources, both demand good performance; as such it pays to know the internals well so as to write performant code. 

For platform specific performance considerations you can also check out the following material on MSDN -

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you