On Tuesday 09 July 2013 12:09, Cedric BAIL wrote : > Hello, > > 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. > > > 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.
have a look at my old http://git.enlightenment.org/core/efl.git/log/?h=devs/jeyzu/eo2 I changed EO_FUNC macro because I wanted to end up with a clean header. > > 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. > > 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. > > >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). > > > 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 ? > > 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. > > Cheers, > -- > 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 --- Hell'O from Yverdoom Jérémy (jeyzu) ------------------------------------------------------------------------------ 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
