On Mon, May 19, 2008 at 12:10 AM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> On Thu, 1 May 2008 03:58:14 -0300 "Gustavo Sverzut Barbieri"
> <[EMAIL PROTECTED]> babbled:
>
>> Hi guys,
>>
>> As you can see from CVS log, I did some repacking of Evas_Object and
>> managed to save more than 80 bytes, almost 1/3 of it is gone.
>>
>> While some aggressive packing went in, like "layer" number being a
>> short now, I'm a bit unsure if applying the attached patch is a good
>> thing. It will save 4 bytes from cur,prev, so it's 8 bytes in the end,
>> but the solution is a bit ugly, as the members
>> cache.clip.{visible,dirty} now are cache_clip_{visible,dirty} so it
>> can be packed with the other bitfields. On one hand it saves memory,
>> on the other it's ugly as hell :-P
>>
>> Apply or not? that's the question...
>
> that is a good q. 80 bytes is not much., 80 bytes per object (where we likely
> have 1000-10000 per app) is 80-800kb of savings. not to be sniffed at. one
> thing i would think might buy a bit is a way to remove the need for the cache
> entries at all - that may be more intrusive though code-wise and possibly lead
> again to the bugs i added those entries in to solve (or require re-calculation
> where now its a simple dirty + recalc where needed then lookup all the time)
>
> as such i think its worth it - even for a bit of ugliness. we could... make..
> macros to hide it? :)
well... we could do it based on transactions support: we would have
just the current state and all *_set() would allocate new state and
fill it, marking a "used" flag somewhere. then when nothing changes we
can just avoid looking at it.
A variation of this solution is to allocate transaction
operations: set would compare with current state and if it's different
a new operation is appended to this list of pending operations. We
could be bit smart and override existing operation (ie: resize1,
resize2 -> resize2).
That said, I guess they will be lots of trouble to implement and most
will make it slower if things get *_set() called a lot (ie:
edje_recalc)... with more pressure on the VM and all this check that
we would have to do. I never did a profile there, but I guess that
these basic property lookups are fast... and AFAIR we already just
check them if o->changed.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
