Avoiding Performance Pitfalls With XAML
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 -