On Sun, 1 Nov 2015 22:22:47 -0200 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> 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. but... did you get any perf numbers? because what you propose is that now wee have to eoid -> obj ptr lookup via table every call and we can't batch and share within an eo_do chunk. > 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. indeed lock-free tables might help too but we can use spinlocks on those which is ok as table accesses for read or write should be extremely short lived. thats MUCH better than tls. > 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. this means the oid lookup each and every time... thats not pretty. :( thus .. perf numbers? sure - atm we do a log of eo_do(obj, func1()); ie only 1 func we don't use the eo_do batches much yet... > 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. my actual profiling shows its the call resolve and fetching of the class data (scope data) that really are costing a lot. those are the huge things - and those have to be done one way or the other. so dropping eo_do doesn thelp at all here. > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
