On Tue, 11 Mar 2014 20:13:07 +1000 David Seikel <onef...@gmail.com> wrote:
> On Tue, 11 Mar 2014 09:46:26 +0000 Tom Hacohen > <tom.haco...@samsung.com> wrote: > > > On 11/03/14 09:22, David Seikel wrote: > > > 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. > > > > Eo2 is known to be coming for about half a year now... > > Like I said, I had marked a bunch of eo related emails to be read, so > it's likely I missed seeing eo2 mentioned. After reading your other > reply on this thread, perhaps I should wait another half a year for > eo2? B-) OK, I went over my backlog of emails, and studied eo and eolian a bit. Seems like it would work to use eolian to generate the edje_lua2.c bindings. I'm guessing it could work like this - Add a --lua option to eolian that generates lua bindings similar to what is in edje_lua2.c. Adding lua_generator.c/h files to eolian. I'm not sure if we should continue to wrap the legacy functions, or wrap eo_add() and eo_do() directly. Add a target in Makefile_Eolian_Helper.am to create *.eo.lua.c files. Add Makefile rules to generate *.eo.lua.c files alongside the *.eo.c/h files. For example, lib/evas/canvas/evas_line.eo generates /lib/evas/canvas/evas_line.eo.lua.c Rip old code out of lib/edje/edje_lua2.c and replace it with, for example, #include "evas_line.eo.lua.c" at the end. Rewrite bits of edje_lua2.c to not have so much pre decelerations, and other munging to suit having this stuff at the end, and generated. Eventually fix up what breaks when eo2 lands. What do you think? -- 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
