Hi, Le lun. 2 nov. 2015 à 09:24, Felipe Magno de Almeida < felipe.m.alme...@gmail.com> a écrit :
> OK, > > So, I tried to take a stab at it during the weekend. > > I think all the optimizations are actually hurting performance. I > wanted to test removing eo_do and the whole machinery for stacks etc. > And just use the _eo_obj_pointer_get. However, for some reason, mixins > and composites stopped working and I don't have much time to > investigate. > > I think this test should be done. Afterall, if we write a lock-free > table_ids data structure, then we would be _much_ better off than > using TLS and allocations all over the place. > And eo_do seems cool at first, but reviewing the code in EFL while > doing this modification we can see that eo_do creates a lot of pain > and workarounds, to name two: eo_do_ret and eo_do_part. And a lot of > others. > > I've #define'ed eo_do to just call the functions within. All the > functions receive the Eo* object which calls on. And to replace > eo_do_super I've added to eolian the generation for > eo_super_function_name which takes as first parameter the Eo_Class > that would be passed to eo_do_super. > > I think that eo_do is very likely hurting performance. So we should at > least prove that it does give better performance before we start using > macros all over the place, which will be necessary to avoid some TLS. > > I pushed the modifications to devs/fellipealmeida/eo_optimizations > if anyone wants to try it out. And, tt is a mess, of course. > > BTW, I'd rather we would keep the optimizations more focused so > we can achieve more. For example, if we depend solely on the > ids_table and function/data lookup (_dich_func_get), > instead of caching results in stacks with allocations and stuff. > Then we can tailor it to make it much more optimized with > lock-free algorithms and better data structures. > This sounds promising. After using EO a bit I have to say I don't really like the eo_do(obj, call()) syntax. On the other hand the obj = eo_add() is nicer than Felipe's changes :) I tested your code a bit, with eo_suite test to see what works. It seems you didn't modify class functions to be class functions instead of object functions, which makes the suite fail. This leads me to this question: Is there (or was there) any reason for class functions to have the same syntax as an object function even though they don't apply to the same kind of "thing"? (Eo_Class vs Eo object) Why are classes Eo objects? (beyond sharing code). I think we can further optimize out some checks if we make a clear difference. Best regards, jp ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
