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/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
