Question

Today, I came across an interesting method of implementing the INotifyPropertyChanged interface. Instead of passing a string name of the property changed, or a lambda expression, we can simply call RaisePropertyChanged(); from the setter, mark that the call is parameterless. This is the code in the RaisePropertyChanged() method:

public virtual void RaisePropertyChanged()
{
    var frames = new System.Diagnostics.StackTrace();
    for (var i = 0; i < frames.FrameCount; i++)
    {
        var frame = frames.GetFrame(i).GetMethod() as MethodInfo;
        if (frame != null)
            if (frame.IsSpecialName && frame.Name.StartsWith("set_"))
            {
                RaisePropertyChanged(frame.Name.Substring(4));
                return;
            }
    }
    throw new InvalidOperationException("NotifyPropertyChanged() can only by invoked within a property setter.");
}

And this is a property that will notify its dependants of its change:

public string MyProperty
{
    get { return _myField; }
    set
    {
        _myField= value;
        RaisePropertyChanged();
    }
}

While I find this approach interesting, I think the performance penalty could be serious in case the property changed often… or if every property in our application used this approach to notify of its change.

I’d like to hear your opinions. (there is no longer the community-wiki checkbox?)
Would this approach be very inefficient?

Source: Article where this approach is presented

Answer 1

I just tested it using this code. (Note that I circumvented the limitation pointed out in Wim Coenen’s answer using the MethodImpl attribute. I have my doubts as to whether this is a surefire workaround.)

Results:

Raised event using reflection 1000 times in 25.5334 ms.
Raised event WITHOUT reflection 1000 times in 0.01 ms.

So you can see, the solution involving the stack trace has about 2,500 times the cost of the “normal” solution.

That’s the proportional answer, anyway. I personally dislike this idea (clever though it may be) for reasons quite beyond performance issues alone; but, obviously, it’s your call.

---

Edit: For the record, I felt compelled to write a blog post about this—in particular, about the fact that some developers would be tempted to use an approach like this in spite of the performance hit.

Whether you agree with my feelings on the subject or not (I realize that the performance hit is small in absolute terms), I feel that the real killing blow to this idea is that, for it to be even remotely robust, it is necessary to decorate every property setter from which you intend to call RaisePropertyChanged with the MethodImpl attribute, passing MethodImplOptions.NoInlining… which, right there, negates whatever typing savings you otherwise gained.

So you’re left with a net loss in development time (by however many seconds it took you to type out the whole MethodImpl attribute part), plus a performance penalty. Very little reason to go this route, if you ask me.