INotifyPropertyChanged vs. DependencyProperty

Question

I need to watch properties for changes. Which method is better in terms of performance and memory use: implementing INotifyPropertyChanged or using a DependencyProperty?

Note: Yes, I have read the other question INotifyPropertyChanged vs. DependencyProperty in ViewModel.

Answer 1

Memory Use: INotifyPropertyChanged is an interface, so close to zero memory overhead. "Close to zero" because I assume you'll be writing an OnPropertyChanged method and maybe some event handlers in other classes (unless you're really just talking about binding to WPF), so there will be a slight code overhead.

Performance: DependancyProperties have alot going on under the covers. Unless you write the most non-performant OnPropertyChanged method ever, I would wager that INotifyPropertyChanged will be the perf winner as well.

Unless you have a defined reason for wanting/needing the behaviors provided by a DP I would just go with INotifyPropertyChanged.

Update

As the comment mentions binding performance is a bit faster for DPs (15-20% faster, but still only a difference of less than 50ms for 1000 binds) due to the amount of reflection needed to to the lookup/hookup of direct properties. This is technically different than the performance of updating a databound UI element which is what my comment was geared towards. But that doesn't mean my wager is still correct either. So a few examples and alot of .NET Reflector digger later it looks... inconclusive. Both paths do a ton of work under the covers and I wasn't able to get any examples to show a definitive difference in update performance.

I still stick with INotifyPropertyChanged unless I have specific need for DPs, but it was at least an interesting exercise to poke around into the WPF core some more. :)

Answer 2

Never mind, I just found the answers I was looking for in the following question.

I'll repost the answer by "LBugnion" (so all credit goes to him) for your convenience:

---

Implementing INotifyPropertyChanged has many advantages over DependencyObjects (I will abbreviate this DO to make it easier) and using DependencyProperties (DPs):

• This is more lightweight
• Allows you more freedom in modeling your objects
• Can be serialized easily
• You can raise the event when you want, which can be useful in certain scenarios, for example when you want to bundle multiple changes in only one UI operation, or when you need to raise the event even if the data didn't change (to force redraw...)

On the other hand, inheriting DOs in WPF have the following advantages:

• Easier to implement especially for beginners.
• You get a callback mechanism (almost) for free, allowing you to be notified when the property value changes
• You get a coercion mechanism with allows you to define rules for max, min and present value of the property.

There are other considerations, but these are the main.

I think the general consensus is that DPs are great for controls (and you can implement a CustomControl with custom DPs even in Silverlight), but for data objects you should rather implement INotifyPropertyChanged.

HTH, Laurent

Answer 3

IMHO, INotifyPropertyChanged is very lightweight and easy to use in comparison to DPs. As far as performance/memory is concerned, do you really need to know? Knuth wants to know.

Obviously, you have to determine your requirements and see how many DP's you're expecting to create/second, how long lived they are, and run a few tests. I've done this before and didn't see any issues with creating short-lived DP's at ~10k/sec (YMMV).

Answer 4

As MSDN says, WPF is quicker at binding to DependencyProperties than to custom CLR objects using INotifyPropertyChanged.

See http://msdn.microsoft.com/en-us/library/bb613546.aspx