GNOME Bugzilla – Bug 595394
g_type_class_(un)ref shouldn't take locks
Last modified: 2009-09-17 10:17:27 UTC
While profiling various gstreamer pipelines/elements... I encoutered a massive cpu usage which breaks down as follows. Create hundreds of thousands of GstBuffer per second (not that uncommon with high-bandwith streams) which: * calls g_type_create_instance() * 26% of that is taken by g_slice_alloc0() * 50% by g_type_class_ref HALF of the time spent to create an instance is spent in g_type_class_ref, which itself breaks down into * 9% type_data_ref_Wm * 37% g_static_rw_lock_writer_lock * 37% g_static_rw_lock_writer_unlock ... does it *really* have to take that lock ? Here's a kcachegrind breakdown of g_type_create_instance's usage: http://people.collabora.co.uk/~edward/g_type_create_instance.png
I lookedat the code in gtype.c and don't see a reason why (un)reffing a type shouldn't be really fast in the normal case (where the type already exists). However, the refcount is currently well hidden in TypeNode->data->refcount - the refcount should likely be moved to the TypeNode directly and in the >0 cases not take a lock (neither for reffing nor for unreffing).
fwiw, wtay's working on native rwlock implementations here : http://cgit.freedesktop.org/~wtay/glib/log/?h=rwlock This should help bringing down the overhead of the rwlock... but as Benjamin mentionned... I still don't see why this needs such a heavy overhead for refcounting the class (compared to the lightweight instance atomic-int-based refcounting).
I'm tempted to mark this as a duplicate of #585375
*** This bug has been marked as a duplicate of bug 585375 ***