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. Best regards, -- Felipe Magno de Almeida ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
