On Thu, May 1, 2008 at 5:11 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> Gustavo wrote:
>
> > 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...
> >
>
> Hey man, I hope you didn't think my remarks about adding
> properties and such had to do with object sizes...
of course no, but having almost 300 bytes for each object was
something I don't like for a long time. I just have some spare time
and went to the code and fixed what was easy. As you can see there is
not much we can do other than that in EVAS, but if you look at Edje...
oh god! With part descriptions over 300 bytes I wonder how we can be
so much lighter than GTK for example (and yes, we are a lot lighter
than, ie matchbox).
> It was more
> about having all these things (including some older stuff) that
> may or may not apply to this or that obj type, no way to know,
> etc. Ideally a "pie in the sky" kind of thing would be an evas
> based on an ecore_object 'object' system (with all the ecore gui
> stuff, including ecore_evas, split off from an ecore base), and
> similar utopian ideals. :)
I think that's overkill at this level. This is better if you take
widgets and like, so can be done in an upper level like ETK or EWL do.
About this I'm particular biased _AGAINST_ ecore_object. It's better
to rely on existing machinery, either "native" going C++ or
Objective-C, or going with GObject or PyObject, saving efforts to
create yet-another-poor-implemented object system in C.
> Anyway... although I'm not sure just how 'important' it is
> (in practice) to have object sizes cut down as much as you managed,
> that's nice work anyhow! But yeah, some of it is a bit 'ugly'...
> maybe leave those parts alone?
the importance is that, except by image data, that's what consume most
of memory in EVAS. Also, making them smaller, consuming less cache
lines, will make applications a bit faster when you're loading batches
of them to RAM... the downside is that now comparisons will need to
apply masks before comparisons and settings, making these a bit
slower, however if you use multiple load/store of values in the same
bitfields, they can be done in one step, so a bit faster.
Also, one of the patches moved data that non-smart objects do NOT
use, and these were confusing and wasting memory.
> BTW, did you kill Kenny with all that chopping away?
:-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--------------------------------------
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
