I’m currently working on my first WPF application, and I’m curious as to whether I’ll hit a snag down the line with performance by doing something like this:
Dim binding As New Binding("PropertyOnObject.Property1.Property2.Value")
binding.Source = Object
vs doing
Dim binding As New Binding("Value")
binding.Source = Object.PropertyOnObject.Property1.Property2
My objects are fairly dynamic, in that PropertyOnObject can change(and thus changing Property1 and Property2), so it makes sense to do it the first way. Is there a performance penalty for that, though?
The second binding will probably perform marginally better, because WPF does not need to traverse the lengthy property path, but it has different semantics. In the first binding, if any of PropertyOnObject, Property1, Property2 or Value changes, the binding will be re-evaluated. In the second binding, the property chain will be resolved when Source is set, and the binding source will be whatever Property2 was at that time. So if (say) Property1 changes to refer to a different entity, that won’t update the binding, because the binding is attached to the Property2 object independently of the reference chain. Only if you change the value on the original Property2 object will be binding update.
Since you want the first behaviour, you need to write the first binding, and pay the minor performance penalty. Writing it the second way may be faster but will give you wrong results.
Note that the performance penalty is going to be insignificant unless you have a huge number of these bindings: you’re operating on a UI timescale here, so a couple of milliseconds here or there just doesn’t matter. Don’t try to optimise the binding unless you can establish that it really is causing a problem.