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!
--
------------- 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
