2009/11/12 Owen Taylor <otaylor redhat com>: > On Thu, 2009-11-12 at 14:57 +0100, Alexander Larsson wrote: >> On Wed, 2009-11-11 at 23:10 -0500, Ryan Lortie wrote: >> >> > The easiest fix here is to link libgio with -pthread. We discussed this >> > at the GTK meeting yesterday and decided to do this unless anyone on the >> > list has a compelling reason not to. >> >> Its certainly an easy fix. However, it will inflict e.g. threadsafe >> malloc and all the other libc functions on all single-threaded Gtk+ apps >> which is not a small cost (although the Gtk+/glib locking will not be >> enabled unless you call g_thread_init()). > > Do we have the numbers for that? The original gthread split was done > based on timings I did in 1999 or so, and if I recall, showed an overall > overhead of 5% or so for allocation intensive GTK+ code (like > constructing a large tree of widgets.) > > 10 years later we have GSlice, a completely different implementation of > threads, and very different processors so it's very hard to extrapolate > from those original measurements. As a quick'n'silly test to get a feel of the difference I did a run of alloc/free benchmark, just doing g_new()&g_free() for 1000 units of the GList struct in a sufficently long loop to spend ~22s doing it. The result? The version with g_thread_init() and built with gthread-2.0 averaged in around 22.00s and the "single threaded" averaged at around 22.6s. Just adding gthread-2.0 to the build but not calling g_thread_init() didn't seem to have any effect at all. So if one would to take this as a fact, please do force initializing threading as it is actually faster than without on my Ubuntu 9.10! :) But I'm totally not sure if the test is sane or reliable. -- Kalle Vahlman, zuh iki fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi
Attachment:
test.c
Description: Binary data
Attachment:
res
Description: Binary data