On Tue, 22 Jan 2013 11:21:08 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> On Tue, Jan 22, 2013 at 7:57 AM, Cedric BAIL <[email protected]> wrote: > > 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. > > Given the nature of it, I guess it's easier to solve like: > > evas_object_event_callback: > 1 - dynamically allocate an array of pointers with size as the > number of elements in EVAS_CALLBACK_* enum: when unused, pointer-size > bytes. When used pointer-size * (elements-in-EVAS_CALLBACK_ + 1) this is a simpler sinmgle-array version of the alist thing i guess. :) > 2 - for each callback, place in the aforementioned array another > inarray of pairs {cb, data}. You can avoid your extra integer cost for > inarray by implementing something manual, it won't hurt that much the > integer, but seems you're bugged about that. The size would be 2 * > pointer-size > > right now we use 4 pointers per node (prev, next, cb, data), plus some > information that due alignment should take an extra pointer-size > (type, priority, delete_me). So 5 pointer-size at least, but on my > machine (32 bits) it's 28 bytes or 7 pointers. > > We can avoid the 'deleted' bit by making cb = NULL in the structure. i like this idea. > If we use inarray (allocated size != used size), we can just swap > deleted elements to the end as well when we cleanup, avoiding > allocations at all. Problem is how to handle the priority part without > loosing much info, I'll count it as an extra-pointer-size. > > Expected gains: > > = empty = > now: 1 * pointer-size > new: 1 * pointer-size > > = 1 event of 1 type = > now: 1 * pointer-size + 1 * (7 * pointer-size) = 8 * pointer-size > new: 1 * pointer-size + 34 * pointer-size + 1 * (3 * pointer-size) = > 38 * pointer-size > > = 10 events of 5 types (50 events) = > now: 1 * pointer-size + 50 * (7 * pointer-size) = 351 * pointer-size > new: 1 * pointer-size + 34 * pointer-size + 50 * (3 * pointer-size) = > 185 * pointer-size > > equation: 1 + N * 7 = 35 + N * 3; N * 7 - N * 3 = 35 - 1; N * > 4 = 34; N = 8.5 > > then it will pay off, but takes a reasonable amount of events (9). The > additional benefit is avoiding memory fragmentation and it would > reduce search for events as you know just events of a given type would > be in the array slot. we could also look at bitpacking. as a general solution something like lz4 of lists/arrays we tend to walk linearly often enough (and that are generally quite static) might be a benefit. i dont know what the overhead of lz4 would be vs some custom done dictionary+delta scheme though. it'd need some research, but for some data i smell there might be a win there. > For evas_object_smart_callback we could optimize if the smart class > declares its signals and just emits that, in this case we can use a > similar approach to the above. > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- 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
