On Mon, 17 Mar 2014 11:56:38 +1000 David Seikel <onef...@gmail.com> said:
> On Mon, 17 Mar 2014 10:08:35 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Mon, 17 Mar 2014 09:59:10 +0900 Cedric BAIL <cedric.b...@free.fr> > > said: > > > > > On Mon, Mar 17, 2014 at 9:14 AM, Carsten Haitzler > > > <ras...@rasterman.com> wrote: > > > > On Mon, 17 Mar 2014 02:50:18 +1000 David Seikel > > > > <onef...@gmail.com> said: > > > >> 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. > > > > > > > > actually the intent is to make a whole new binary (eolian-lua) > > > > most likely - same for c++ or anything else, not add an option to > > > > eolian. > > > > > > Why not ? Having one binary and multiple backend would make sharing > > > infrastructure easier and reduce the need for us to release any > > > public API for Eolian until a few release from now. I do not see > > > the win in splitting binary that will have the same command line > > > and do the same job except at the last stage when they output the > > > file. > > > > given that the c++ eolian binding generator is in c++... and that d5 > > (q66) insists the lua bindings generator is far easier to write in > > lua... they're going to be different binaries. > > Well, if q66 is writing it, then maybe, but I was looking at it with > the intention of writing it myself. I'd prefer to do what Cedric said. well his intent is to generate LUA - lua that uses luajit ffi to call native directly. > > also eolian that generates the original c stubs vs a bindings > > generator are vastly different purposes. they may read the same eo > > file src but they produce entirely different things. > > ... and ... > > > unless the newly generated lua is 100% compatible with the old. no .. > > we can't rip it out. you can only create a new parallel api. > > My intention IS to generate C that is 100% compatible with the old > edje_lua2.c code. In the same way that eolian is currently being used > to replace C code. Not entirely different at all, they both generate C > stubs from the same .eo files, the C stubs wrap the same eo functions. > Makes sense to me to clone the eo1 generator, but have it output > slightly different C code. then you'll have to create a new set of eo files and thus classes that 1:1 match the current edje lua api, and then have these generate c... and thats very much different to what q66 was planning. i think you're creating a custom generator for edje lua here with custom eo classes exposed from edje to the edje lua. :) > There's nothing wrong with the way edje_lua2.c works, it's just a pain > writing all that boiler plate C code for the actual bindings. totally agree. and thus it becomes a pain to maintain, extend etc. etc. :) > Remember, we are not generating Lua code, we are generating C code. > Though my LSL to Lua translator generated the Lua code in C as well. > B-) > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- 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
