g_slice_

[mortenw gnome org (Morten Welinder)]

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.
* Don't say overhead for the same reason.

What do we pay?

* We have probably killed tools like Purify that know about malloc
  specifically.
* 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.

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)".