Question

When reading the documentation it seems that WPF uses reflection to bind to CLR objects. In my app I bind a DataGrid to a IList<T> containing only 250 items (each with 8 properties). The DataGrid is using virtualization, so it only fetches the properties for 30 items or so. The properties are all simple strings, and still it takes several hundreds of milliseconds, which is way too long if you compare it to the 40 msecs it took to generate that list via a complex database query.

Are there any tricks to improve the binding time?

Answer 1

So, this is a guess, but It’s happened to me before and it’s worth a shot. Before guessing though, have you profiled your code to see exactly which calls are taking the most time? I believe you when you say that the time increases dramatically when using binding, but the suggestion I am about to give can be proven or disproven with profiling results. Anyway…

I worked on an app a while ago that generated a lot of small UI elements. Each element was an instance of UserControl and used data binding for its appearance. I noticed that, when generating many (200+) of these elements there was an appreciable lag.

We were using Prism and its ViewModelBase class, passing in delegates to the RaisePropertyChanged method, i.e.,

private int _foo;
public int Foo
{
    get { return _foo; }
    set
    {
        if( _foo != value )
        {
            _foo = value;
            RaisePropertyChanged( this.Foo );  // trouble
        }
    }
}

The problem with this is that the implementation of RaisePropertyChanged must use reflection to get the property name as a string. When a lot (and I mean a lot) of these were being fired off there was a significant performance hit.

The solution? Use a string instead of the function object. Yes, that’s really all it took. It stinks a bit as you have to remember to change two things if you ever refactor that property, but honestly the performance degradation is not worth it in many circumstances.

Anyways, give it a shot. If a lot of CPU time is being spent inside RaisePropertyChanged that is likely why.