Re: Introspection API

[Owen Taylor <otaylor redhat com>]

On Fri, 2005-02-25 at 17:39 +0000, Gustavo J. A. M. Carneiro wrote:
> On Fri, 2005-02-25 at 12:10 -0500, Owen Taylor wrote:
> >On Fri, 2005-02-25 at 11:08 -0500, John Ehresman wrote:
> >> Matthias Clasen wrote:
> >> > Is using libffi or something similar a problem ? 
> >> 
> >> I think we want to set things up so libffi could be easily used.  In 
> >> other words, the information that libffi needs should be easily 
> >> obtainable from the introspection api.  I'd also like not to have to 
> >> wrap everything in GValue's if that can be avoided.  That said, we need 
> >> to figure out how to package libffi for non-gcc compilers such as MS VC++.
> >
> >libffi in my memory has a pretty horrid interface, and I think there
> >is some value in wrapping in something more GLibish. 
> >
> >GValue has significant performance problems,
> 
>   I was not aware of this, and it's an unpleasant surprise to find it
> out, considering how GValue is used extensively in gtk+
> (properties/signals).

Do some profiling on signal emission and you'll see the GValueTable
stuff at the top. I know how we can basically work around it there,
but it requires breaking the GValue abstraction .. that's fine
inside libgobject, but dubious for a public invocation API.

[..]

> > g_function_desc_invoke (GFunctionDesc    *desc, 
> >                         const GArgument  *in_args,
> >                         int               n_in_args,
> >                         const GArgument  *out_args,
> >                         int               n_out_args,
> >                         GArgument        *return_value);
> >
> >Where GFunctionDesc is the API object for FunctionBlob. (I forget
> >what it was called in Matthias's writeup.) You'd also want the reverse
> >marshaling from C to GArgument.
> 
>   Right.  That looks like an interesting API to use by bindings.  Of
> course, I don't really know what GArgument contains...

GArgument would just be something like:

 union {
   int v_int;
   double v_double;
   void *v_pointer;
   [...]
 } GArgument;

>   It worries me that we already have PyObject<->GValue conversion code
> in pygtk, but we'll have to create new conversion code for
> PyObjec<->GArgument.  Are you sure GArgument is going to get us any
> performance improvement at all?  If in doubt, I'd stick to GValue.

Oh. I'm positive there is a performance difference:

 arg.v_pointer = object;

Should be several *hundred* (thousand?) times faster than:

 memset (&value, sizeof(GValue), 0);
 g_value_init (&value, G_TYPE_OBJECT);
 g_value_set_object (&value, object);
 [...]
 g_value_unset (&value); 

It's much more competitive to have:

 value.g_type = G_TYPE_OBJECT;
 value.data[0].v_pointer = object;

But currently that isn't considered legitimate usage of GValue API
at the present time.

Regards,
						Owen