On Mon, Aug 10, 2009 at 1:39 PM, Cedric BAIL<cedric.b...@free.fr> wrote:
> 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 ?) ?

Edje_Part_Description is fixed size, would match perfectly fixed size
mempool allocators.


-- 
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

Reply via email to