On Tue, 11 Mar 2014 16:20:37 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> so now we're getting more into eo... it's time to look at 3 things > that turn up on my profiles of things that are NOT expedite. > > 8.21% elementary_test libeo.so.1.9.99 [.] eo_do_internal > 7.77% elementary_test libeo.so.1.9.99 [.] _ev_cb_call > 3.03% elementary_test libeo.so.1.9.99 [.] > eo_data_scope_get > > this is a pretty simply test. open elm test. scroll to bottom, scroll > back to top. close. almost 20% of our cpu is spent in the above 3 > calls. it's time to cut this down... a LOT. > > so i am looking at _ev_cb_call() and callbacks in general. this is a > single linked list of cb's for ALL cb's for an object. we filter out > cb's not matching the callback type (desc) as we walk the list. this > of course causes us to do a lot of cache misses and hunt through a > lot of memory to then... do nothing. > > imho this needs to be restructured to... > > 1. have fewer linked list nodes. that means instead of: > > node (cb) -> node (cb2) -> node (cb3) ... > > what might be better is: > > node (cb1,cb2,cb3,cb4,cb5,cb6,cb7,cb8) -> node > (cb9,cb10,cb11,cb12) ... > > ie bigger buckets with more cb's per buckets, fewer links. possibly > have a cb "optimizer" that figures out if the cb list has been > changed since it last optimized and then might group all cb's into a > flat array (if cb's are removed, array is split at that point and > fragments until the next optimize call). this should save a little > memory too. > > 2. but much more important here is to divide cb's into type specific > lists/arrays so we don't walk tonnes of cb's we then filter out, and > to have a fast "select" to select the appropriate list to walk for > that event (as we call 1 event at a time only - but all cb's for that > event). That sounds like a great idea. > 3. global freeze_count AND object freeze count is checked in the > inner loop per walk, and not outside the loop before even beginning a > walk! these should at least be checked first to abort any callback > list walk that we KNOW will all fail. we know the desc is unfreezable > direct from the input desc and don't need to use the > cb->items.item.desc. > > ... comments? > > now eo_data_scope_get()... i can't find much to imptove here... the > mixin path isn't hit often and data_sizes are notmally > 0... so some > way to oprimize: > > if (EINA_LIKELY((klass->desc->data_size > 0) && > (klass->desc->type != EO_CLASS_TYPE_MIXIN))) return ((char *) obj) + > _eo_sz + klass->data_offset; > > is most likely what's needed... but there isn't much there. :) > > now eo_do_internal()... i think we need to wait for eo2... TOM! I finally have some time this week (unless a client wants me to be busy) to look at this eo stuff, and now you tell me that eo2 is coming? lol I'll be going over all the old emails I have marked, try to learn how eo works, and consider if it can be used for the Edje Lua stuff. I think it's either eo for Lua bindings, or LuaJIT FFI. Manually writing the Edje Lua bindings is obviously not so good, I kinda balked at all those text APIs. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
