Hello, On Tue, Jul 16, 2013 at 12:35 AM, Tom Hacohen <tom.haco...@samsung.com> wrote: > On 09/07/13 04:09, Cedric BAIL wrote: >> On Tue, Jul 9, 2013 at 2:00 AM, Tom Hacohen <tom.haco...@samsung.com> wrote: >>> The hero Jeremy Zurcher has been playing around and looking for ways to >>> improve Eo and address all the issues that have been raised by everyone. >>> We revisited some old ideas, tried some new ideas and changed our >>> compromises and preferences to better suit our needs (followed by the >>> extensive trial period). We think we made things better and we'd like to >>> hear your thoughts and suggestions. >>> >>> The code resides in devs/tasn/eo2. The differences are not major >>> usage-wise (i.e eo_do), but are major internally and class-creation-wise. >>> There's an example of the usage of the new API in the eo2test directory. >>> The existing code-base hasn't been changed to use the new API, so >>> there's not a lot to review. >>> Eo2 is not complete, we'd like to hear your thoughts before finishing >>> things. >>> >>> Major changes: >>> 1. No more va_args, good ol' normal functions instead. >>> 2. Functions are resolved in eo and then called directly, creating a >>> "flatter" backtrace. >>> 3. We can have return values (to some extent). >>> 4. Less boiler-plate. >>> 5. Looks like we'll be able to get rid of some code thanks to this change. >>> 6. Possibly (probably) faster on platforms that pass parameters in >>> registers. >>> 7. Easier to do breakpoint on a specific eo_do call, instead of an >>> implementation. >> >> Sounds like valid point. >> >>> What we'd still like to achieve: >>> 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be >>> best to find a way to use the function pointers (for example) as the >>> IDs, but the problem is, that because function pointers are more >>> "unknown" we can do less optimisations on them which we'd like to avoid. >>> 2. Reduce more boiler-plate. >> >>> Haven't been implemented yet: eo_do_super (among many other things). >> >> There is more FIXME lurking around also in eo.c in your branch. >> > > Yes. > >>> Additional comments: >>> EO_FUNC - this one creates a function that resolves and returns the >>> appropriate function. The functions created using this macro should be >>> used instead of the current eo macros. This one can potentially be improved. >>> eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and >>> possibly other stuff in the future). >> >> I have some issue with EO_FUNC. The main one being that I really can't >> get what the parameter of the created function are. Reading a header >> full of those will be completely useless to me ! The readability of >> that macro should really be improved. Also the eo2_do macro lead to >> weird eo_o parameter for all function call. This seems like a >> duplication and source for potential error. > > You can't do it otherwise. Well you can have an EO_CALL macro like > Jeremy likes, but I hate it, it's more of a mess. If you have an idea, > please let me know and I'll try it.
Maybe defining a macro with the same name after the function definition to automatically add the parameter. But that would be hugly to. I have yet to find an idea that I like. >> The second problem I see is that we are going to push a lot of >> pressure on the compiler with all this functions. Every EO_FUNC will >> be a static inline function, there is going to be a massive number of >> them in all our headers, slowing down compilation quite a lot. > > True, well, we can make them symbols instead, but I didn't want to > increase the symbol count. I think making them inline will give an > advantage in that regard. An advantage you also agree with. Yup, just a complain if someone got an idea on how to improve things, and no using a macro instead would be worth. >> On a debugging and tracing ability, we do loose some ability there. >> There is no easy way to hook before and after the function call at >> this stage. This could be useful for many tools. Like Daniel's espion, >> that does something like strace but to an efl application. Or my >> starting attempt to do a performance analysis by knowing from which >> klass the function come from and where we do spend time. > > I disagree. You can hook on the eo_do_begin and eo_do_end calls in > eo_do2. That will give you exactly the same. No. Having hook on eo_do_begin and eo_do_end calls are way off what we want to look at. We want every operation. I am thinking about adding to function pointer set to NULL by default that will be used in the EO_FUNC_BODY macro, before and after the function call with all the parameter given to it. > >From an optimization perspective, it would be good to mark eo_func_get >> as being 'pure' so it will eliminate multiple call if they are on the >> same object. Also did you do any benchmark comparing the previous use >> of eo_do with your new approach ? Right now using Eo doesn't slow us >> down, I would be interested to see a comparison of the same example >> (CPU, library size and used memory). > > I haven't done any benchmarks, it's an API mock-up at the moment, not a > full blown implementation one can compare to. There are more details to > be ironed out before that. You are late on that one ! We already tried that with Jeremy and it doesn't work, see another mail on the subject for an explanation on why. >>> Looking forward to hearing what you have to say. >> >> Eo is one of the biggest change we did for 1.8. At this stage it is >> optimized to a point where we don't feel the cost compared to 1.7. It >> may be even faster in some work load and use less memory. Any major >> change like this is going to have an impact on any release for 1.8 (We >> are already 2 months late and will likely be 3, so what is it to add 2 >> more months delay). A major question is how fast can you roll your >> change in EFL ? > > The answer: I don't know. It depends if we really want it. German Daniel > claims that there are tools that can help me do it. I think it'll take > me more time to do it by tools than by hand + sed, will see though. Would be great if we had a tool to do that in a day ! >> That lead to an equivalent question, how many people have yet reviewed >> your proposal and are in favor of the change or have idea to improve >> it. I may want to put some pressure on that side, as I am really upset >> by our current delay on 1.8 and I really want to ear more than one >> voice in favor of another huge delay. > > Well, no one is saying anything either way. It's like Eo1. People were > quiet until it was too late to complain. Expect the same. :) Snif ! You are breaking all hope in me this morning. -- Cedric BAIL ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
