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?
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.
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
