Page MenuHomePhabricator

elementary: Efl.Ui.Image now rely on event to update model binding.
ClosedPublic

Authored by cedric on Thu, Jul 11, 4:06 PM.

Diff Detail

Repository
rEFL core/efl
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
cedric created this revision.Thu, Jul 11, 4:06 PM
cedric requested review of this revision.Thu, Jul 11, 4:06 PM

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?

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?

My concern here is, even if this event is at low speed, the fact that you register the event callback impacts all the other events emitted on the object, in a very hard way.

My concern here is, even if this event is at low speed, the fact that you register the event callback impacts all the other events emitted on the object, in a very hard way.

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.

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.

cedric updated this revision to Diff 23457.Wed, Jul 17, 12:01 PM

Rebase and take comment into account.

bu5hm4n accepted this revision.Wed, Jul 17, 12:11 PM

And then he said "lets do it later"

This revision is now accepted and ready to land.Wed, Jul 17, 12:11 PM
Closed by commit rEFLa68e18a903ff: elementary: Efl.Ui.Image now rely on event to update model binding. (authored by cedric, committed by Marcel Hollerbach <mail@marcel-hollerbach.de>). · Explain WhyWed, Jul 17, 12:59 PM
This revision was automatically updated to reflect the committed changes.