On Tue, 18 Mar 2014 12:42:18 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Mon, 17 Mar 2014 23:14:15 +1000 David Seikel <onef...@gmail.com>
> said:
>
> > On Mon, 17 Mar 2014 12:16:34 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> >
> > > 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. :)
> >
> > Why are new classes needed?
>
> example:
>
> edje lua:
>
> _elua_geom() / obj:geom(x, y, w, h)
>
> eo:
>
> geometry_set() / geometry_get()
>
> it's geometry even not geom. so any methods generated are going to
> usse geometry. it's listed as a property so thus in c/c++ it'll get
>
> eo_do(obj, evas_obj_geometry_set(x, y, w, h),
> evas_obj_geometry_get(&x, &y, &w, &h));
>
> and
>
> obj->geometry_set(x, y, w, h);
> obj->geometry_get(&x, &y, &w, &h);
>
> (actuallly not sure if in c++ we'll add evas_obj_ or not)
>
> so in lua either u get full methods for both
>
> obj:geometry_set(x, y, w, h);
> obj:geometry_get(...); // unsure
>
> (also not sure of evas_obj_)
>
> or you expose it as a table property (not sure here).. but no matter
> what.. geom != geometry. in edje lua it's obj:geom(x, y, w, h); or
> geom = obj:geom();
>
> so just starting there the method/property naming doesn't match.
> you'll find this is the case everywhere. they won't match.
OK, so that explains parallel API, which can still be done by cloning
and tweaking the eo1 generator C file and adding --lua to eolian.
Where there is differences, mark the old manual stuff as deprecated,
but keep it around for a bit.
If q66 is gonna do his version, then I'll just drop this idea entirely,
no need to debate it. B-)
> > Currently ealion produces this from the existing evas_line.eo files
> > -
> >
> > EAPI void
> > evas_object_line_xy_set(Evas_Object *obj, Evas_Coord x1, Evas_Coord
> > y1, Evas_Coord x2, Evas_Coord y2) {
> > eo_do((Eo *) obj, evas_obj_line_xy_set(x1, y1, x2, y2));
> > return ;
> > }
> >
> > EAPI void
> > evas_object_line_xy_get(const Evas_Object *obj, Evas_Coord *x1,
> > Evas_Coord *y1, Evas_Coord *x2, Evas_Coord *y2) {
> > eo_do((Eo *) obj, evas_obj_line_xy_get(x1, y1, x2, y2));
> > return ;
> > }
> >
> > And the relevant part of edje_lua2.c is currently -
> >
> > static int _elua_line_xy(lua_State *L)
> > {
> > Edje_Lua_Obj *obj = (Edje_Lua_Obj *)lua_touserdata(L, 1);
> > Edje_Lua_Evas_Object *elo = (Edje_Lua_Evas_Object *)obj;
> > Evas_Coord x1, y1, x2, y2;
> >
> > if (!_elua_isa(obj, _elua_evas_line_meta)) return 0;
> >
> > if (_elua_scan_params(L, 2, "%x1 %y1 %x2 %y2", &x1, &y1, &x2,
> > &y2) > 0)
> > {
> > evas_object_line_xy_set(elo->evas_obj, x1, y1, x2, y2);
> > }
> > evas_object_line_xy_get(elo->evas_obj, &x1, &y1, &x2, &y2);
> > _elua_ret(L, "%x1 %y1 %x2 %y2", x1, y1, x2, y2);
> >
> > return 1;
> > }
> >
> > Most of that is boilerplate that's common to the rest of the
> > bindings. What's left is the same as what eolian already outputs,
> > the specific function names and the argument types/names. There's
> > no need for custom EO classes here, or a new set of .eo files.
> > Just copy the existing eo generator, and tweak it a little should
> > work fine.
> >
> > What q66 is planning seems like a LOT more work. And as Cedric
> > mentioned, duplicates work that is already being done by eolian.
> >
> > > > 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. :)
> >
> > So something needs to be done. If q66 is planning to do his version
> > using LuaJIT FFI then I guess I don't need to do it. I can leave
> > it up to him, and go poke at Bob or something else. Unless he has
> > plans for Bob to?
> >
> > --
> > A big old stinking pile of genius that no one wants
> > coz there are too many silver coated monkeys in the world.
>
>
--
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
