Depends on D9288
I am wondering here a bit why this is needed. If i am looking recently to the performance problems, most of the time is spend in event callbacks in just too many event subscriptions, is there a reason for this to reply on the event?
Main reason is that the only way to know there is a model being set in all case is with watching the event :-)
As for performance issue, this is a low speed event, it will happen very rarely and shouldn't become an issue. Most of our trouble, as far as I know, come from to many event emit not on the receiving end of them, right?
That shouldn't be the case as the event callback is a sorted array, we should have a very fast log(N) walk of it. Registering one more handler shouldn't have any noticeable impact. Do you have some test case I could later play with? So far, most of the cost come from high speed repeated walk with no handler listening (like resize, move and so on).
The event callbacks are *not* sorted, the arrays are sorted, but the array itself is not sorted. And if you look at resent performance issues, most of them are caused by the fact of having a long event subscription array that gets walked for a shitload of events in shutdown. this is why i am a bit concenred with something like this.
Oh! We might have some potential speedup there. Will have to look at some point. I could make this event register only when a property is bound to the object that should alleviate your concern.