Re: BonoboUnknown & G_SIGNAL_TYPE_STATIC_SCOPE

[Michael Meeks <michael ximian com>]

On Fri, 2002-01-04 at 02:07, Tim Janik wrote:
> hm, i doubt you'll notice that, the code reads:
>
> #define MAX_STACK_VALUES        (16)
...
> so unless you have more than 16 signal arguments, you get your values on the
> stack anyway.

	I missed that - I confess; but you might do better to always alloca on
that basis - I doubt that we ever need of the order of hundreds of
parameters :-) and a simpler flow is always better - no ?

> out of curiousity, do you actually have any profiling data which exposes the
> signal system lock?

	Nope - I just heard rumours of slowness from Frank around this spot.

> but yes, reviewing that code once more, the lock in
>   for (i = 0; i < node->n_params; i++)
> is easily moved out of the loop.

	Great.

> i went for better-be-safe-than-sorry when adding locks to gsignal.c,
> so there might be other places where locks could be optimized (probably
> not in signal_emit_unlocked_R() though, which i fryed my brain over for
> several times ;)

	Heh :-)

> yep, but like my initial guesses and some preliminary profiling results
> showed, the majority of that is currently due to g_value_{s|g}et_*() for
> every argument in every marshaller and i have strong intentions to fix
> that prior to 2.0 (glib-genmarshal still needs some extensions, little
> fixes and some aggresive optimizations).

	Oh - ok; is it not the case that we do rather a number of possibly
redundant type checks [ is that the slow thing ? ] - certainly for base
types it's a waste of time to do:

	value_init (val, G_TYPE_CHAR);
	...
	val->v_char = pull_char_off_stack;
	...
	get_value_as_char ():
		g_return_val_if_fail (G_VALUE_HOLDS_CHAR (value), 0);

	where G_VALUE_HOLDS_CHAR is always a method invocation (?) perhaps
_G_TYPE_CVH is gagging for an inline type pre compare optimization ?
especially given the locking overhead of type_check_is_value_type_U and
grief; well - there's a lot of code behind g_type_check_holds_value ...

	Might this patch not accelerate things somewhat markedly for base types
? or have I misunderstood something fundamental ?:

Index: gtype.c
===================================================================
RCS file: /cvs/gnome/glib/gobject/gtype.c,v
retrieving revision 1.43
diff -u -p -u -r1.43 gtype.c
--- gtype.c	2001/12/13 07:04:41	1.43
+++ gtype.c	2002/01/04 10:24:34
@@ -2742,7 +2742,13 @@ gboolean
 g_type_check_value_holds (GValue *value,
 			  GType   type)
 {
-  return value && type_check_is_value_type_U (value->g_type) &&
g_type_is_a (value->g_type, type);
+  if (!value)
+    return FALSE;
+
+  if (value->g_type == type)
+    return TRUE;
+
+  return type_check_is_value_type_U (value->g_type) && g_type_is_a
(value->g_type, type);
 }
 
 GTypeValueTable*

> yep, my priority queue is along
> 1) settling API
> 2) bug squashing
> 3) optimizations
>
> i'm currently working on (2)

	I'm so pleased we're past 1 :-) but great I see that 3) should be some
fun.

> so there's been very little optimization
> work going on so far (basically typedef gsize GType; was pushed because
> it was an API issue to some extend).

	Sure.

> to relieve you some, the GUI part of beast is unbearably slow currently,
> so i'll definitely tackle that once the worst glib/gtk bugs are addressed.

	I'm glad beast is unbearably slow :-) that does relieve me lots. It
would be nice to have some signal emission performance tests though in
glib so we can get a metric for how fast emissions are on each
architecture, and whether our optimizations are in fact working :-)

	Regards,

		Michael.

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