On Sat, Aug 15, 2009 at 7:20 AM, Carsten Haitzler<ras...@rasterman.com> wrote: > On Mon, 10 Aug 2009 12:21:11 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > >> 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. >> >> BTW, something that could improve memory there is using mempool. > > even mempool will fragment. it isnt necessarily a silver bullet. not > allocating > is better than anything else :) i am wondering if simple N structs with > casting > is best (and a common header in all for common members for all types).
Yes, and this is really the best solution BUT with current fscking huge code it's very hard to do. As I said to cedric, go and do a refactor to isolate parts dealing with common bits or specific (text, textblock) in separate functions, than errors will be harder to happen. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
