On Tue, 11 Mar 2014 09:31:47 +0000 Tom Hacohen <tom.haco...@samsung.com> said:
> 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. actually this is the base class.. this shouldnt change for eo2.. right? event cb's are still the same. i was just bringing it up to see if there is any love being shown to this atm, and if so - what kind of love (or thoughts about love) :). butthis does definitely figure in profiles... prominently enough for me to read it. :) the freeze thing is trivial. an extra check and abort before doing anything (even the ref/unref) would be an obvious fast path. yes - still needs doing per call too in case one cb freezes. you CANT thaw back to working... if u are already thawed as u cant call anything to make the thaw happen... :) the q really is.. how to optimize this. cedric pointed out that the cb arrays have DIFFERENT cb types per array member - that is annoying as that nukes the idea of optimizing the entire data structure in-place as we need to keep the original array... so what would work is where we build an optimized func+data array per desc "seen" by the callback caller - the first time it sees an event desc and it has no optimized array, it builds one (either with N entries, or empty) and any time you add or del callbacks, you nuke the optimized arrays and rebuild next call. this though will require we need to track how often these arrays are used and if not used often they need to be "garbage collected" (so we really use them as a cache). or that's my current thinking... it does mean we duplicate data though (func ptr + data ptr), but it is a packed array of these per desc and then likely an rbtree or hash indexed by desc ptr so we can find the right unique desc func call array immediately. but this means adding a bitfield (we have spare space at the struct end) and then needing to overload callbacks to first point to the optimized btree (which then points to the first real Eo_Callback_Description member as well as btree base). this avoids adding another ptr to the struct and bloating out and means we find the optimization btree first, but complicates callback add/del. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
