On Mon, 10 Aug 2009 18:39:23 +0200 Cedric BAIL <cedric.b...@free.fr> said:
> On Mon, Aug 10, 2009 at 5:21 PM, Gustavo Sverzut > Barbieri<barbi...@profusion.mobi> wrote: > > On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment > > SVN<no-re...@enlightenment.org> wrote: > >> Log: > >> * edje: Reduce sizeof (Edje_Calc_Params). > >> > >> Note: It doesn't really impact edje memory foot print yet. But in > >> the plan to do a computation cache inside edje, this structure > >> will be used a lot (I am planning to do this feature at some point, > >> but no ETA yet, and be reassured it will be optionnal so we can > >> choose between CPU load or memory load). > >> > >> Note: As I was looking for similar area of improvements, > >> Edje_Part_Description could really use an union to reduce it's size, > >> but as we load this structure directly from an Eet file, we need > >> union in Eet first. And this should be part of a comming Edje file > >> format break. > > > > Better than union is to have the single part in one structure and > > specific bits in their own structure. Depending on how we do the Eet + > > union support, we may think on how to do it to cover this case as > > well. > > > > I'd say instead of allocate memory and fill it, one could give a > > "type" value to user callback and then it would receive the correct > > Eet_Data_Descriptor for that subtype. So union would return the data > > descriptor with the same struct size for all types, while dynamic > > would check (switch/case) which one to use, and return the fields > > properly. > > > > This is likely to reduce memory consumption a lot because we often > > have LOTS of rectangle that have almost no field, while we have very > > few TEXT/TEXTBLOCK/GRADIENT that consume most memory. > > Hum, that's another possibility, this is almost like implementing some > object "inheritence" support in eet. This could be much more efficient > than using union, but only if type can't change, or you could be > forced to reallocate another structure. But this seems more usefull > than union for Edje. Will put this somewhere in the TODO :-) > > > BTW, something that could improve memory there is using mempool. > > I don't really see how, what do you want to put inside this mempool > (one per type of edje object ?) ? but Edje_Calc_Params is runtime - not in the .edj file :) no need to worry about eet here. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
