Re: [E-devel] More aggressive packing of Evas_Object
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-1 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/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] More aggressive packing of Evas_Object
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-1 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? :)
PS: please test Evas on as many
machines/architectures/compilers/operating systems as possible to see
nothing is broken by these patches! It relies on compilers working
fine with bitfields.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] More aggressive packing of Evas_Object
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...
PS: please test Evas on as many
machines/architectures/compilers/operating systems as possible to see
nothing is broken by these patches! It relies on compilers working
fine with bitfields.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
? lib/engines/common_16/libevas_engine_common_16.la
Index: lib/canvas/evas_clip.c
===
RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_clip.c,v
retrieving revision 1.30
diff -u -p -r1.30 evas_clip.c
--- lib/canvas/evas_clip.c 8 Feb 2008 22:35:19 - 1.30
+++ lib/canvas/evas_clip.c 1 May 2008 06:49:57 -
@@ -8,7 +8,7 @@ evas_object_clip_recalc(Evas_Object *obj
int nx, ny, nw, nh, nvis, nr, ng, nb, na;
if (obj-layer-evas-events_frozen 0) return;
-// if (!obj-cur.clipper-cur.cache.clip.dirty) return;
+// if (!obj-cur.clipper-cur.cache_clip_dirty) return;
evas_object_coords_recalc(obj);
cx = obj-cur.geometry.x; cy = obj-cur.geometry.y;
cw = obj-cur.geometry.w; ch = obj-cur.geometry.h;
@@ -21,13 +21,13 @@ evas_object_clip_recalc(Evas_Object *obj
if (obj-cur.clipper)
{
// this causes problems... hmmm
-// if (obj-cur.clipper-cur.cache.clip.dirty)
+// if (obj-cur.clipper-cur.cache_clip_dirty)
evas_object_clip_recalc(obj-cur.clipper);
nx = obj-cur.clipper-cur.cache.clip.x;
ny = obj-cur.clipper-cur.cache.clip.y;
nw = obj-cur.clipper-cur.cache.clip.w;
nh = obj-cur.clipper-cur.cache.clip.h;
- nvis = obj-cur.clipper-cur.cache.clip.visible;
+ nvis = obj-cur.clipper-cur.cache_clip_visible;
nr = obj-cur.clipper-cur.cache.clip.r;
ng = obj-cur.clipper-cur.cache.clip.g;
nb = obj-cur.clipper-cur.cache.clip.b;
@@ -44,12 +44,12 @@ evas_object_clip_recalc(Evas_Object *obj
obj-cur.cache.clip.y = cy;
obj-cur.cache.clip.w = cw;
obj-cur.cache.clip.h = ch;
- obj-cur.cache.clip.visible = cvis;
+ obj-cur.cache_clip_visible = cvis;
obj-cur.cache.clip.r = cr;
obj-cur.cache.clip.g = cg;
obj-cur.cache.clip.b = cb;
obj-cur.cache.clip.a = ca;
- obj-cur.cache.clip.dirty = 0;
+ obj-cur.cache_clip_dirty = 0;
}
void
@@ -57,7 +57,7 @@ evas_object_clip_dirty(Evas_Object *obj)
{
Evas_List *l;
- obj-cur.cache.clip.dirty = 1;
+ obj-cur.cache_clip_dirty = 1;
for (l = obj-clip.clipees; l; l = l-next)
evas_object_clip_dirty(l-data);
}
@@ -67,7 +67,7 @@ evas_object_recalc_clippees(Evas_Object
{
Evas_List *l;
- if (obj-cur.cache.clip.dirty)
+ if (obj-cur.cache_clip_dirty)
{
evas_object_clip_recalc(obj);
for (l = obj-clip.clipees; l; l = l-next)
Index: lib/canvas/evas_object_gradient.c
===
RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_object_gradient.c,v
retrieving revision 1.21
diff -u -p -r1.21 evas_object_gradient.c
--- lib/canvas/evas_object_gradient.c 1 May 2008 04:14:08 - 1.21
+++ lib/canvas/evas_object_gradient.c 1 May 2008 06:49:59 -
@@ -918,7 +918,7 @@ evas_object_gradient_render_pre(Evas_Obj
/* if someone is clipping this obj - go calculate the clipper */
if (obj-cur.clipper)
{
- if (obj-cur.cache.clip.dirty)
+ if (obj-cur.cache_clip_dirty)
evas_object_clip_recalc(obj-cur.clipper);
obj-cur.clipper-func-render_pre(obj-cur.clipper);
}
Index: lib/canvas/evas_object_image.c
===
RCS file: /cvs/e/e17/libs/evas/src/lib/canvas/evas_object_image.c,v
retrieving revision 1.63
diff -u -p -r1.63 evas_object_image.c
--- lib/canvas/evas_object_image.c 1 May 2008 00:09:39 - 1.63
+++ lib/canvas/evas_object_image.c 1 May 2008 06:49:59 -
@@ -2036,7 +2036,7 @@ evas_object_image_render_pre(Evas_Object
/* if someone is clipping this obj - go calculate the clipper */
if (obj-cur.clipper)
{
- if (obj-cur.cache.clip.dirty)
+ if (obj-cur.cache_clip_dirty)
evas_object_clip_recalc(obj-cur.clipper);
obj-cur.clipper-func-render_pre(obj-cur.clipper);
}
Index: lib/canvas/evas_object_line.c
Re: [E-devel] More aggressive packing of Evas_Object
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...
PS: please test Evas on as many
machines/architectures/compilers/operating systems as possible to see
nothing is broken by these patches! It relies on compilers working
fine with bitfields.
I'll try on windows with mingw. Indeed, i've forgotten to add
-mms-bitfields in the compilation flags in the efl, which is needed if
other programs use evas and are compiled with ms vc++ if i'm not mistaken.
See:
http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00253.html
There is a description of that flag
Vincent
PS: unit tests...
-
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
Re: [E-devel] More aggressive packing of Evas_Object
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... 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. :)
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?
BTW, did you kill Kenny with all that chopping away?
-
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
Re: [E-devel] More aggressive packing of Evas_Object
On Thu, May 1, 2008 at 4:18 AM, Vincent Torri [EMAIL PROTECTED] wrote:
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...
PS: please test Evas on as many
machines/architectures/compilers/operating systems as possible to see
nothing is broken by these patches! It relies on compilers working
fine with bitfields.
I'll try on windows with mingw. Indeed, i've forgotten to add
-mms-bitfields in the compilation flags in the efl, which is needed if
other programs use evas and are compiled with ms vc++ if i'm not mistaken.
See:
http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00253.html
There is a description of that flag
hum, I doubt that will matter because all the structs are internal to
evas, so just evas object code, which was compiled with mingw, so use
the correct instructions, will access these bitfields.
Vincent
PS: unit tests...
no time for them now, after recompiles I ran pahole and analyse, then
expedite and then e... for the first time I made enums a bitfield I
wrote a small application outside evas that did that and it worked.
--
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
Re: [E-devel] More aggressive packing of Evas_Object
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
Re: [E-devel] More aggressive packing of Evas_Object
Gustavo wrote: 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. I'd have to disagree with this. Even if it's just for toolkit use that one is concerned with, it would be very useful for some toolkits to have evas objects as part of the same object system as the widgets, some may even build the widgets by extending evas objects if they wished, or extending the base object that evas objects also extend, etc. But just in evas itself this would be extremely useful - many reasons for that. 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. Ok, now there you're going to have political as well as logical 'issues' with various people. :) I think an ecore_object 'object' system upon which to build things like evas,edje,toolkits,... would be very useful. Even if you wanted to use gobject you could still have ecore_object built on top of it, but then you might as well replace most of ecore with glib and relatives... and this is going to be a 'political' issue with some people here. As far as using other higher-level libs, c++,obj-c,c#,java,... well, I'm sure you'll have some nice debates with people as to why and why-not one or the other. :) 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. Some of it was nice, and the addition of the min/max values for layers was a *very* good idea (actually, something like that might be good for limits to coords and size values as well). But some of the others may just be more of a pain to deal with than any 'real' gains for practical use (that means run-time and develop-time), it depends. - 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
