Re: g_slice_

[mortenw gnome org (Morten Welinder)]

It sounds to me that you had two pieces of code that sucked: the
glib mempools and the glibc malloc.

Well known.  Both Gnumeric and Evolution wrote their own specialized
pool allocators because of that.  (Why two?  Because we didn't know
about each other.)

I don't think I should compare slices to memchunks because that is not
what I have been using.  I have configuring with "--disable-mem-pools
--enable-gc-friendly" for ages.  Add in using a less bogus malloc and
you have a better baseline.

So my working Purify support is now gone.
So my one piece of hot allocation code is now two.
So I now have two, not one, allocators keeping seperate free lists.

You could have avoided the memchunk bogosity by using the malloc-
wrapping you introduced in early November.  That would have been
an obvious improvement with none of the downsides.  Improving
glibc's malloc would probably be a good idea too.

Which brings me to...  What data structures in glib programs (existing
and predicted in the next few years) are (a) used multi-threaded, and
(b) used often enough to warrant performance considerations?

I see GList nodes, GSList nodes, and GHashTable nodes.  Maybe that leaves
out one of two, but the scale is right.

This had better be what you are optimizing for.  Not, for example:
> - if you use n CPUs (n>1), you want to be able to allocate n times the
>   amount of memory of a single CPU per time interval, and not just be safe
>   against concurrent allocations
> - if you consider one allocator per thread, take into account that chunks
>   may be allocated in one thread and freed in another
Those are fine considerations.  Just not for glib.

Add to that, that the number of C programmers who can write working
threaded applications is even smaller than the number of C programmers
who can write code that doesn't leak enough to be a problem.  You are
not going to see many multi=threaded C applications using glib.  And if
threading is taking place in a higher language, it isn't clear that
malloc is where you need the smarts.

Morten