On 09/07/13 04: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. >
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. > > 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. > > 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. > >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. > >> 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. > > 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. :) -- Tom. ------------------------------------------------------------------------------ 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
