gobject profile ... (fwd)

[Michael Meeks <michael ximian com>]

Hi there,

	This may or may not be appreciated - but, I'm profiling test-ui in
a nice tight loop doing 1000 batched sets; to see if any obvious
bottlenecks come out ( with CVS HEAD libbonoboui/test/test-ui and
eazel-tools/prof/prof incidentaly ):

	Either way I get:

Per function collation

1212 samples:

__pthread_mutex_lock                                             :  15% ( 176 )
__pthread_mutex_unlock                                           :  13% ( 156 )
g_static_rw_lock_reader_lock                                     : 6.1% ( 74 )
g_static_rw_lock_reader_unlock                                   : 5.9% ( 72 )
signal_handlers_foreach_matched_R                                : 4.9% ( 59 )
g_signal_emit_valist                                             : 4.3% ( 52 )
g_type_value_table_peek                                          : 3.1% ( 37 )
g_type_check_instance_cast                                       : 2.5% ( 30 )
g_type_instance_is_a                                             : 2.2% ( 27 )
signal_emit_unlocked_R                                           : 2.1% ( 26 )
malloc_check                                                     : 1.2% ( 15 )
g_value_type_compatible                                          : 1.2% ( 15 )
g_param_spec_pool_lookup                                         : 1.2% ( 14 )
g_value_set_instance                                             : 1.2% ( 14 )
g_hash_table_lookup                                              : 1.2% ( 14 )
free_check                                                       : 1.1% ( 13 )
g_quark_from_string                                              : 0.91% ( 11 )
g_type_is_a                                                      : 0.83% ( 10 )
gtk_signal_emit                                                  : 0.83% ( 10 )
g_signal_connect_closure                                         : 0.74% ( 9 )
__libc_free                                                      : 0.66% ( 8 )
g_object_unref                                                   : 0.66% ( 8 )
g_value_object_collect_value                                     : 0.66% ( 8 )
g_signal_emit                                                    : 0.58% ( 7 )
gtk_widget_set_parent                                            : 0.5% ( 6 )
xmlParserInputBufferGrow                                         : 0.5% ( 6 )
xmlParseAttribute                                                : 0.5% ( 6 )
g_signal_connect_object                                          : 0.5% ( 6 )
g_object_notify                                                  : 0.5% ( 6 )
g_type_check_value                                               : 0.5% ( 6 )

	Anway - as you can see, we hit a lot of things before anything I
have control over (superficialy, although clearly not algorithmicaly). And
worse - it seems that locking is swallowing a huge chunk of the time, far
outweighing anything else - at 40% of the time ... :-)

	So. It seems over the codebase, mostly we have constructs of the
type:
	static GMutexType *amutex = NULL;
...
	if (g_thread_supported ())
		amutex = new_mutex ();
...
	if (amutex)
		take_lock (amutex);

	etc. which seems to serve us well and good for Gdk etc. etc.

	So is there any good reason why the type_rw_lock in gtype.c is not
handled this way ? I'm happy to pay the locking penalty if I'm using it,
but ...

	Would you appreciate a patch that made this locking conditional on
threads being initialized ( as elsewhere ) ? if so I'll knock one up.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot