On Tue, 22 Jan 2013 18:57:36 +0900 Cedric BAIL <[email protected]> said:
> Hello,
>
> I have been chasing source of memory consumption in EFL since a few
> weeks now. There is one source that I didn't hunt yet, callbacks. In
> some small elementary_test they easily get over 400KB of
> Evas_Func_Node. This func node are not that big, but they are still a
> list with a function pointer, two integer and a data pointer.
> When we look at our usage, in a lot of place, we do have the same
> pattern. We register a set of callbacks for always the same event with
> the function pointer and priority. The only thing that change is the
> data pointer.
> Instead of using a list, we could use an array, that would reduce
> our memory use, but still, not enough. Maybe overall, it wouldn't even
> b a win if we use an Eina_Inarray or an Eina_Array as they do require
> two additional integer, so the base structure when you have no
> callbacks will be bigger.
> So what we could do is provide an API to register a static const
> array of function pointer and event like an callback class. This
> pattern would match our use in Edje, Elementary and even Terminology.
> One "class" of callback per object, instead of n instance of callbacks
> per object. That should really reduce the memory we use for that.
> I don't want to push this new API in Evas, because we have that
> pattern with edje signal, smart callback and object callback. I think
> it should go to Eo and we should move our code to use such API.
>
> Any comments, though on that subject.
> Have fun,
i don't like this api idea. :( especially when we are trying to simplify and
unify callback stuff with eo. but i guess it would work... but it means u have
to create a callback "blob" from a callback class... and that blob holds data
ptr passed to each fn in the class fn ptr list/table... given a union you can
get down to:
struct fptr {
void (*func) (void *data, ...);
void *data;
};
struct ftab {
void (*func[]) (void *data, ...);
void *data;
};
struct cb {
short pri;
short type;
union {
struct fptr func;
struct ftab functab;
} d;
};
so we're down to "3 ptrs" worth per item and an item can be either a normal func
node OR a funtab node (where func is a pointer to a null terminated array of
callback ptrs).
now assume we get rid of the list.. and we pack everything into an array...
what we need is a "arraylist" (alist?) in eina. where its a linked list of
ARRAYS. ie u get a block of 8 or 16 or 32 "items" in a packed array... and THEN
a linked list pointer to the next block. this will allow us to really pack stuff
much more nicely. if done flexibly, there is some default block size, but we
allow any block to be any size in # of sub elements. we don't realloc blocks -
ever, if we delete an item we just shuffle down elements and make the end of
the array block unused.
what we want is a "pack" call on this "alist" that can take blocks and "merge
them" into a single array (or a list of arrays of no more than N items each)_
so this can "defragment" a list of blocks or optimize it (by having a tail
block that has room for 32 items but holds only 1 to become a block of just 1
item). this means we could use more memory while building but still keep it
efficient as we do things in blocks of N which covers the most common cases
better BUT then at some later point (eg idle time) we can walk over objects
"defragmenting" such lists while idle (mark lists that have been defagmented
and not changed since defrag).
imho this would help with the problem and provide infra for a whole host of
similar problems. also it'll speed up the array walk by a huge amount due to
cacheline prefetch as opposed to scattered walk through memory... :) ie dont
make alist just handle void *'s for items but handle any "blob" of n bytes.
that means it can be a sizeof(void *) OR sizeof(callback_func). eo can later
use this too. :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
