Re: [Tracker] some patches

[Carlos Garnacho <carlos imendio com>]

Hi!,

On Thu, 2008-02-14 at 17:31 +0100, Laurent Aguerreche wrote:
> Le mercredi 13 fÃvrier 2008 Ã 18:09 +0100, Carlos Garnacho a Ãcrit :
> > Hi!,
> >
> > This was just a heads up to these three bugs:
> >
> > #513692 : This one just packs booleans in guints, so it should improve
> > size in most used structs.
>
> Is it so interesting to save some bytes this way?
>
> In tracker-utils, this patch will replace 25 gbooleans with 25 "uint:1".
> If I assume that gboolean is a typedef of gint and that gint uses 4
> bytes, this patch will save (25*4)-25 = 75 bytes (perhaps a little bit
> more but IMHO not much more because we use pointers everywhere and we
> take care of memory allocations).
> So we would prefer to write some weird things (using of unsigned int
> instead of booleans) to save ~75 bytes?

There are several copies of such structures during all the application
lifetime, so if you save for example 16 bytes (5 gboolean = 20 bytes, 1
guint = 4 bytes) in one structure, having say 100 of these structures
around saves you already 1600 bytes. To me it's a no brainer trying to
get used to do such effortless improvements as you code.

> Another question: why glib does use a typedef of gint instead of a
> typedef of "guint:1" for its booleans?

This is only applicable to structs and unions, and the define would have
to get like:

#define gboolean(var) guint (var) : 1

quite weird for a data type.

> > #513691 : a similar improvement to #511788 (already committed) in a
> > different function.
>
> +     res = g_ptr_array_sized_new (100);
>
> What is "100"?!

Perhaps should have done a #define for that :), it's just a good enough
default value, so the array has a sensible initial size, and it doesn't
need too frequent reallocations when the array grows at first.

Regards,
  Carlos