silverlight performance tip

原文：http://www.ganshani.com/2009/07/10/silverlight-2-best-practices-iii/

Locally defined StaticResource fails to load

When a StaticResource object is both defined and referenced inside the same element, the Preview Window will fail to load with an error “The type StaticResource was not found.” 

Hence, it is advisable to keep Static Resources in App.xaml file. This also helps usage of these resources across the modules in the application.

Share a Brush than copying it

Instead of defining Brush in XAML, define it as StaticResouce and reference it. This creates only one instance and then reuses it.

Generic TODO list:

This is more of a compilation of single-liners that aptly fit in the TODO list of a Silverlight developer.

-          Naming Convention – Casing:
Pascal Casing and not Camel Casing is preferred (unlike in C#).  myButton is wrong in Silverlight though it is correct in C#. The correct version is MyButton.

-          Use x:Name instead of Name as x:Name is generic and can be used for all elements.

-          Indentation:
Place first attribute in-line with the element name like.
<StackPanel
    DockPanel.Dock=”Top” Orientation=”Horizontal”>

-          Choose a StaticResource over DynamicResource. For further read, click here

-          Resources should be placed at one location, preferably at Application Level in App.xaml file. This will avoid reloading of resources over and again when objects are created and destroyed.

-          SnapsToDevicePixels – Using graphic objects can appear nice on some monitors, while it may fade on others.  It is preferred to use a Style resource in such scenarios. For more read, click here

-          Define a definite folder structure before starting application development

·         Services – to have WCF service references

·         Images – to store application images and videos

·         Resources – platform specific APIs

·         Data – to store XML, text files

-          Remove the Object Handlers when not in use.  Not removing object handlers may keep the object alive, which may degrade the performance

-          RegisterClassHandler is called on every instance of object creation, which may cause performance problems

-          Frozen objects over Non-frozen:
Frozen objects occupy lesser memory space and are fast in execution. Consider the example on MSDN

-          Prefer VirtualizingStackPanel (40mSec) over a simple StackPanel (takes 3000mSec for same UI) to speed up the execution time.

-          Avoid using a TextBlock in FlowDocument

-          Since Label.Content property is slow in execution, TextBlock.Text should be used. (This is one reason why Label is not a part of Silverlight framework, and it is part of WPF)

-          Show underline in Hyperlink only on MouseOver events.  TextDecoration is performance intensive.

-          Bind an IList to an object, not an IEnumerable to avoid an automatic wrapper creation.  This will enhance your performance.

-          Proper node at proper place:
While the tree is developed, there can be two approaches – bottom-up or top-down. A top-down approach is 10 times faster. This is because when a node is added or removed from the logical tree, property invalidations are raised on the node’s parent and all its children.