From: Gustavo S. B. <bar...@pr...> - 2009-08-10 15:21:23
|
On Mon, Aug 10, 2009 at 6:56 AM, Enlightenment SVN<no-...@en...> 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. BTW, something that could improve memory there is using mempool. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |