Expensive Calls to FindName
Silverlight elements come with a great method called
FindName(). In a nutshell, FindName allows you to find an element anywhere in the hierarchy in any direction. This in itself is a blessing and a curse.
The positive side of this is that it allows you to quickly reference an element in the tree without having to resort to recursive method calls or holding your own reference collections. It has been something that has been asked for in ASP.NET so you can search down the tree where as currently FindControl() only looks one level deep.
The negative however, is the performance. FindName as it turns out is a very expensive call to make and your performance will suffer. At first look, it seems like the obvious choice inside a Silverlight event handler to find an element. The standard event handlers look like this: function event_handler(sender, args). calling sender.FindName("MyElement") easily returns your element of choice but with the performance issues.
While running tests in an application that made use of this call, we started to notice the performance problem. When running animations in subsecond time, IE and Firefox started to lag noticably. Firefox even popped up a message box alerting me to a slow script running on the page.
Reflector to the rescue! Essentially when you call FindName(), a recursive search is done up the tree to find the top-most parent element. Once this element has been found a
HybridDictionary is searched to find the element you are looking for. This HybridDictionary contains all the elements below the parent in a map. As a sidenote, a HybridDictionary internally uses a
ListDictionary if the collection is small and then switches over to a
HashTable for lookups once the collection is large enough to store the data.
Interestingly, as an x:Name doesn't need to be globally unique in the context of templates, styles and storyboards and any other XAML elements, the FindName() does walk up the tree until it finds the nearest NameScope which holds the above mapping of element names. So there exists a chance that the recursive search for the parent that owns the NameScope may not have to walk the entire tree and may stop pretty quickly. This sounds like another blog post to explain how NameScopes work and I'll delve into it then.
So, to reflect, to find a single item, an element has to do a recursive search for the top-most parent and then do a search inside a HybridDictionary for the element reference. As you can imagine this is not a very fast method of retrieving references and you do take a performance hit if running through Javascript (as you will be if using 1.0).