Re: g_slice_

[Behdad Esfahbod <behdad cs toronto edu>]

On Sat, 3 Dec 2005, Morten Welinder wrote:

> I might be dense, but what exactly does g_slice_ buy us over
> plain, old malloc?
>
> * Don't say speed.  That's a bogus argument because you cannot
>   possibly have tested all mallocs.

It's tested with the glibc implementation, and that buys us speed
over the malloc at hand.

> * Don't say overhead for the same reason.

What overhead do you mean here?  g_slice allows for allocating
small pieces of memory without any additional bytes wasted.  For
example, a GSList node will take 8 bytes instead of 16.

> What do we pay?
>
> * We have probably killed tools like Purify that know about malloc
>   specifically.

There can be a environmental variable to make g_slice malloc each
request, for that purpose.

> * We have more overhead now since both malloc and g_slice_ will
>   keep their own free pools.
> * More code (now malloc and g_slice_), both likely to be kept
>   hot by the cpu cache.
>
> I just don't see it.  Trying to outdo an unknown malloc is hubris.
>
> If you had wanted something marginally fancy, you could have taken
> goffice's pool allocator.  It comes with:
>
> * Free leak detection support.  You can iterate over leaked pieces.
> * You can free a whole pool without freeing the pieces (but then
>   you cannot detect leaks, of course).
> * O(1) ability to give back memory to the system when chunks become
>   free.
>
> For better [speed] or worse, it isn't currently thread safe.  That
> could be trivial to add, though.

Seems like that's not quite trivial, to make it scale.  The
original bug (#118439) has the relevant discussion.

behdad


> Morten
>
>
> -----------------------------------------------------------------------------
>
> Unrelatedly,
>
> why drop type-safety for the non-gcc case?  Something along these
> lines ought to work:
>
> #define g_slice_free(type, mem) \
>   do { \
>     if (1) g_slice_free (type, mem); else (void)((type*)0 == mem); \
>   } while (0);
>
> In the gcc case you need to supply a non-macro definition of g_slice_free.
> Otherewise the resulting program is not valid, regardless of that
> "while (0)".
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"