Re: g_slice_

[Andy Wingo <wingo pobox com>]

Hi Morten,

I'll bite.

On Mon, 2005-12-05 at 10:44 -0500, Morten Welinder wrote:
> 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 trust you saw Tim's earlier mail replying to Paul LeoNerd Evans. There
are quite a number of structures there. To serialize their
(de)allocation via a lock around a mempool is very unperformant. Anyone
writing MT programs should applaud the concern that Tim and Matthias
have given to MT performance.

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

GStreamer uses GLib and is highly multi-threaded. These mempools were
showing up high in my benchmarks when I was profiling GStreamer's
overhead. Pushing this threadsafe pooling down to GLib gets it out of
Gnumeric, evolution, gstreamer, etc. Maybe one day it can make it into
glibc itself, who knows.

Just some data points,
-- 
Andy Wingo
http://wingolog.org/