On Thu, Feb 04, 2016 at 04:07:58PM +0000, Tom Hacohen wrote: > On 04/02/16 15:58, [email protected] wrote: > > Hi, > > > > On Thu, Feb 04, 2016 at 03:48:17PM +0000, Tom Hacohen wrote: > >> On 04/02/16 15:18, Hermet Park wrote: > >>> my point is not EINA_UNUSED nor animator. > >>> > >>> As you mentioned, event_info is used for sometimes. > >>> > >>> How many scenarios will use those event_info and desc in the future? > >>> Im worring about our code is getting more long and dirty because of this. > >>> See our evas_object_smart_callback and evas_object_event_callback > >>> function prototypes. > >>> > >>> I'm curious if we could provide simpler version. > >> > >> event_info: a lot. > >> desc: debatable, though maybe bindings will make good use of it to ease > >> attaching to callbacks. We are not entirely sure, but we wanted it > >> because we had some cases in mind (that I don't remember at the moment) > >> where we thought this could prove useful. > >> > >> smart callbacks have event_info, and it's useful, so I don't see your > >> point. > > > > Why not having something like > > > > _event_cb(void *data, Event *ev) {...} > > > > with > > > > typedef struct { > > Eo *obj > > Eo_Event_Description2 *desc > > void *event_info > > } Event; > > > > I wouldnt put *data in this structure since its more often used than > > obj/desc/event_info. > > > > I'll write here what I wrote on IRC so everyone can see. > > I love this idea, but I do have some comments, one of which may mean > this change is not be feasible. > > It really solves our problem with unused, and it actually feels elegant. > obj is also used, maybe not as often as data, but also often used. > Either way, data is almost always cast and set to a local variable, so > how often it's used doesn't really matter, so if we go down this path, > we should move everything there. > > I have one major issue with this approach though. Performance. On most > modern ABIs function parameters are passed in registers (first few). > Your change will change register assignment (passing parameters) to > memory assignment (setting the local struct). Memory caches nowadays are > really fast, so maybe it won't pose an issue, but it is a concern we > need to check. Another issue is the redirect (memory read) when > accessing the members of this struct vs a register read. > > This may sound like nothing, but callbacks are a very hot path in the > EFL and we work very hard to make them fast. >
In the end the event like above will only be created once. This means there is only the access at the beginning of the emittion. So it keeps being no memory operation from event callback to event callback. And as TAsn mentioned on IRC only data changes between event callbacks. > -- > Tom. > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
