Does unnecessary NotifyPropertyChanged calls cause performance issues?

Question

In my new WPF Application, I am reusing a Model class. In that model class, all the properties, in their setters, fire NotifyPropertyChanged. In my application, I do not really have a use case of firing INPC for individual property. I need to know that if I keep the current architecture where individual properties fire INPC every time they get changed, will it cause any performance implications? Does it make sense to have individual properties fire INPC when it is not required?

Have you established that you *actually have* performance issues which might be the result of `INotifyPropertyChanged` subscriptions? If not, this is an example of [premature optimization](http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize) — casperOne, May 17 '11 at 15:51
@casperOne: True. However, since INotifyPropertyChanged is a commonly-used pattern, this is a question of general interest. — Heinzi, May 17 '11 at 15:57
Related - you should implement `INotifyPropertyChanged` whenever using a data binding to prevent memory leaks: https://stackoverflow.com/a/27069346/492 — CAD bloke, Jan 29 '20 at 18:18

Muad'Dib · Accepted Answer · 2011-05-17T16:00:26.500

6

Generally speaking, anytime you are running a piece of code that you don't have to, you are potentially causing performance issues.

As a rule of thumb, when you write your setters for your properties instead of just setting your backing field and raising the change event, you should check the equality before you notify, thus avoiding unnecessary updates.

for example:

public int MyInteger 
{
   get { return this._myInteger; }
   set { 
         if ( value != this._myInteger )
         {
            this._myInteger = value;
            RaiseChangedEvent("MyInteger");
         }
      }

you should also check for attached events in your RaiseChangedEvent methods, so if there are no listeners, you don't throw a null reference exception and you don't unnecessarily make a call:

private void RaiseChangedEvent(string propertyName)
{
   var changedHandler = this.PropertyChanged ;
   if ( changedHandler != null )
      changedHandler(this, new PropertyChangedEventArgs( propertyName ) );
}

edited May 17 '11 at 16:00

answered May 17 '11 at 15:50

Muad'Dib

28,542
5
55
68

Yes. Makes sense. Just wanted to confirm my suspicion. Looks like if I cant remove those INPC calls, may be I'll add some extra checks. I'll try your later check for changeHandler. I do not have it in place at this point. – online19 May 17 '11 at 18:19
You can also save instances of PropertyChangedEventArgs in static fields so you will no need to recreate them each time. Saw this in Cinch framework – v00d00 May 18 '11 at 08:08
yes, there are many ways to optimize this, i like to pass a delegate instead of a string to avoid the minefield THAT causes. – Muad'Dib May 18 '11 at 13:48

score 2 · Answer 2 · answered May 17 '11 at 15:51

When firing the PropertyChanged event, you should have something that looks like:

private void NotifyPropertyChanged(string name) {
    if (PropertyChanged != null) {
        PropertyChanged(this, new PropertyChangedEventArgs(name));
    }
}

If PropertyChanged is null, then there are no listeners attached to your event. So there is minimal, if any, impact on performance.

If there are listeners, then you need the raise the event so they will be notified of changes.

also written as `PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));` — CAD bloke, Jan 29 '20 at 18:14

score 1 · Answer 3 · answered May 17 '11 at 15:50

1

If nothing is attached to the events for those objects, then there shouldn't be much of a performance penalty, though you're still executing code and so there'll be some difference compared to removing it.

answered May 17 '11 at 15:50

Tim

14,999
1
45
68

I do have my datagrid bound to the entire object. I do expect live updates on these objects. But mostly these updates involve replacing the record with the new one. – online19 May 17 '11 at 15:53
In the case of your datagrid, the grid is listening to an observable list of sorts, so if you're replacing one record with another, it should be done via replacing one object with another in the list (vs setting each property of an existing object). This would raise one event. How, you're going to have listeners listening to each property of each object in the visible area of the grid, but if the changes are in the vein of complete replacement, those property events shouldn't fire in those cases. – Rich May 17 '11 at 16:07

score 0 · Answer 4 · answered May 17 '11 at 15:55

INotifyPropertyChange is an event, it fires when there is any changes(changes here means value changes)in property which are binds to controls, ideally it depends on the code written in these event, otherwise it is not a overhead but it is not a good practice to have INotifyPropertyChange for every property of your class

Does unnecessary NotifyPropertyChanged calls cause performance issues?

4 Answers4