On 11/03/14 07:20, Carsten Haitzler (The Rasterman) 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). > > 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! >
We'll be switching to Eo2 soon which changes (and improves?) things in many ways. There's no point hacking deeply into the eo1 code just before we are switching. I'll reply to this email, but let's revisit this after Eo2 is in. Eo2 can only go in after the Eolian switch has been completed. 1. We support callback arrays (let's users register for a list of callbacks instead of just one), which improves this, but yeah, we should probably have an automatic optimizer. This should be the same/as bad as normal evas callbacks. 2. Sure. :) 3. I think I copied that from Evas (didn't want to change the behaviour). I guess it's meant to let people freeze events from inside a callback, which makes sense. Yeah, we could add a quicker abort too. Eo2: As I said, waiting for Eolian. Might be able to go in soon. -- Tom. ------------------------------------------------------------------------------ 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
