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. 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
