We have two applications which make extensive use of the Telerik control suite in the front end. They are Prism based, and make extensive use of dynamic module loading to build the UI based on the users configuration.
For example, we have a screen that is a bit like iGoogle. The user can add various kinds of panels to various tabs. It uses the Telerik tab control and the tree view and grid view components. At run time we make a WPF call to get the configuration for the user, and based on that using Prism and Unity we construct the appropriate views etc.
Performance is inadequate, profiling with dotTrace the biggest problem is our nested loops building tabs and the panels on the tabs, and at the root of that is the various calls to LoadComponent:
These are taking from 50 to 500ms depending on the complexity of the particular control. In the case of treeviews and grids, it's in the 400-600ms bracket for /each/ panel.
We desperately need to improve the performance of this.
There are two things I'm interested in to try and address this.
1) Loading all the panels in parallel on background worker threads
2) Working out why LoadComponent is so slow, and seeing if it can be worked round
For 1, we quickly changed the for loop to work launching background worker threads. This worked /very/ nicely for the tabs, they are parallel and instant. However, the components don't work. The engineers investigating think the problem is that the telerik components when being created on the backgroundworker thread are trying to do something that requires the UI thread, and thus they fail and we never get them to render. Because they are child components, possibly looking for the parent object?
Is there anything in this? Is there a recommended way of parallel dynamic loading objects to save them occurring in series and delaying load? And without blocking the UI.
Also, with LoadComponent, if we're loading 10 tree views from the same XAML definition, is there any short cut we could take? (2 on my list)