typesafe NotifyPropertyChanged using linq expressions

Question

Form Build your own MVVM I have the following code that lets us have typesafe NotifyOfPropertyChange calls:

public void NotifyOfPropertyChange<TProperty>(Expression<Func<TProperty>> property)
{
    var lambda = (LambdaExpression)property;
    MemberExpression memberExpression;
    if (lambda.Body is UnaryExpression)
    {
        var unaryExpression = (UnaryExpression)lambda.Body;
        memberExpression = (MemberExpression)unaryExpression.Operand;
    }
    else memberExpression = (MemberExpression)lambda.Body;
    NotifyOfPropertyChange(memberExpression.Member.Name);
 }

How does this approach compare to standard simple strings approach performancewise? Sometimes I have properties that change at a very high frequency. Am I safe to use this typesafe aproach? After some first tests it does seem to make a small difference. How much CPU an memory load does this approach potentially induce?

Answer 1

What does the code that raises this look like? I'm guessing it is something like:

NotifyOfPropertyChange(() => SomeVal);

which is implicitly:

NotifyOfPropertyChange(() => this.SomeVal);

which does a capture of this, and pretty-much means that the expression tree must be constructed (with Expression.Constant) from scratch each time. And then you parse it each time. So the overhead is definitely non-trivial.

Is is too much though? That is a question only you can answer, with profiling and knowledge of your app. It is seen as OK for a lot of MVC usage, but that isn't (generally) calling it in a long-running tight loop. You need to profile against a desired performance target, basically.

Answer 2

Emiel Jongerius has a good performance comparrison of the various INotifyPropertyChanged implementations.

http://www.pochet.net/blog/2010/06/25/inotifypropertychanged-implementations-an-overview/

The bottom line is if you are using INotifyPropertyChanged for databinding on a UI then the performance differences of the different versions is insignificant.