A question recently came up over on the LINDUG about a particular method of implementing INotifyPropertyChanged. This interface has always been used for databinding, but has gained new importance with WPF and SilverLight binding. Writing code inline to each property can be tedious and the poster had a creative solution involving a static method to handle the logic. In his implementation, your properties look like this:
We got to discussing the alternatives, and possible performance implications, and another poster pointed out that saving lines of code does not always equal better performance. So, out of curiosity, I thought I’d do a little test.
This code implements INotifyPropertyChanged in three different ways.
- Inline- with all of the logic inside the property setter, and no base class.
- StaticBase – with a static method inside a base class, similar to the poster.
- InstanceBase – with an instance method inside a base class
It then tests each with 10 iterations of 100000 calls to set CustomerName, and averages the number of ticks. Unfortunately, the test is inconclusive at this point. The times are just too close. Plus, with each run of the test, a different method is fastest, which means that some internals to .NET, such as garbage collection or some other factor, are skewing the results:
Average instance time: 84166
Average static time: 82924
Average inline time: 80326
Average instance time: 78257
Average static time: 78422
Average inline time: 75133
All is not lost, though. We can use NDepend to examine the code. In terms of IL Instructions:
- Inline is 63 IL Instructions, and has no base class.
- StaticBase is 21 for the subclass and 54 for the base class, or 75 total IL instructions.
- InstanceBase is 19 for the subclass and 50 for the base class, or 69 total IL instructions.
So, strictly speaking, inline has fewer instructions total, but using a base class makes more sense if you have more than one class inheriting from it. As we added classes, InstanceBase would be a narrow winner. It also has the lowest cyclomatic complexity by one or two points.
But there’s still one more tool we can throw at this. Visual studio’s .NET built-in profiler instruments or samples the app and measures the total time an app spends inside a particular method. As with the timed tests, the results varied, but generally favored the static approach.
I’m not sure my tests are conclusive at all, but the static approach may have a slight performance advantage. In retrospect, this makes sense, as Microsoft Design Guidelines recommend marking methods static when possible:
After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code.
Of course, this doesn’t necessarily mean everything should be static- in this case the static approach necessitates some additional code that nearly erases any performance benefits. In both cases, the use of ‘ref’ is also questioned by MS design guidelines. In the end, there are probably more significant bottlenecks to worry about, but it’s always interesting to dig into stuff like this. My recommendation: create a base class to help reduce repetitive code with an approach that doesn’t use ‘ref’, or use something like CSLA.