On Mon, Apr 14, 2008 at 12:38 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 11:55 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
> > On Sun, Apr 13, 2008 at 9:52 PM, Gustavo Sverzut Barbieri
> > <[EMAIL PROTECTED]> wrote:
> > > On Sun, Apr 13, 2008 at 1:33 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
> > > > On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL <[EMAIL PROTECTED]>
> wrote:
>
> > > - evas_array seems very useful, make it available to evas as a
> > > whole! Just have it to take "void *" and it will do just fine. Also,
> > > I'd make the increase amount (16) configurable after the array is
> > > created (or provide an alternative constructor).
> >
> > Good idea, but as this are small functions and some are used a lot I
> > like the idea of seeing them inlined. As there are more of this kind
> > of function in Evas, small functions used a lot, I did move them after
> > some profiling inside src/lib/include/evas_inline.x. This give us a
> > little bit of speedup with only a small increase in library size. The
> > function that could be inlined are :
> > - evas_object_is_opaque
> > - evas_event_passes_through
> > - evas_object_is_visible
> > - evas_object_clippers_is_visible
> > - evas_object_is_in_output_rect
> > - evas_object_is_active
> > - evas_object_coords_recalc
> > - evas_object_clip_recalc
> >
> > Are people interested by this kind of patch ? I would add
> > evas_object_array_push to this list also.
>
> Because code is better than discussion, here is a patch that does
> exactly that. Comment are welcome :-)
I like it. It could be dangerous for externally used calls, but for
those exported in evas_private.h, it makes sense.
I just think that some functions should be split in 2 parts: common
and corner, just the common part should be inline, while the corner,
usually bigger, should be regular function defined in evas_private.h.
This would avoid code growing too much while giving us the fast common
path. For example: evas_array_push will not have to realloc most of
times, so it should be in another function:
// defined in some evas_private.c
void
_evas_array_grow(Evas_Array *array)
{
void *tmp;
unsigned int total;
total = array->total + 16;
tmp = realloc(array->obj, sizeof(void*) * total);
if (!tmp) return;
array->obj = tmp;
array->total = total;
}
// defined in some evas_private.h
static inline void
evas_array_append(Evas_Array *array, void *data)
{
if (array->count == array->total) // maybe use unlikely() here, see
gcc info, builtin_expect
_evas_array_grow(array);
array->obj[array->count++] = data;
}
Also, for _internal_ things I really dislike null-pointer checking: we
should never have one, if we do then we are buggy and must crash ASAP
to catch the error sooner. Just entry-point should do these checks to
make library robust.
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
