On 02/11/15 09:03, Jean-Philippe André wrote: > Hi, > > Le lun. 2 nov. 2015 à 09:24, Felipe Magno de Almeida < > [email protected]> 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.
Hey, I''ll better review Felipe's suggestions soon, but regarding your concerns: They used to be separate, they got merged in order to share code and "interfaces" (i.e not needing separate eo_class_do). Splitting can probably lead to some improvements, and we should take a better look into this option (it's already on my TODO list). Maybe if we name the functions nicely, e.g. eo_do for the normal call, and eo_cdo (C for class), we can gain all the benefits, and mostly share code behind the scenes. -- Tom. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
