Re: BonoboUnknown & G_SIGNAL_TYPE_STATIC_SCOPE

[Tim Janik <timj gtk org>]

On 4 Jan 2002, Michael Meeks wrote:

> On Fri, 2002-01-04 at 02:07, Tim Janik wrote:

> > 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;

this is actually a method invokation as well.

> 	...
> 	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 ?:

it's not going to end up with a remarkable speedup, because
type_check_is_value_type_U() simply does an array lookup without
locking and returns TRUE for the common case (note the
node->mutatable_check_cache optimization hack i added some while back).
and because g_type_is_a() is pretty fast (and doesn't need a lock either)
if value->g_type == type.

it seems though, that _G_TYPE_CVH() is a candidate for the kind of
optimizations that are done for _G_TYPE_CIT(), at the same cost however,
that is, it'll produce false positives if you pass it a broken GValue and
simply check for its first gsize member (which isn't necessarily a valid
value type id).

> 
> 	Regards,
> 
> 		Michael.
> 

---
ciaoTJ