Re: Introspection API
- From: Owen Taylor <otaylor redhat com>
- To: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Cc: language-bindings gnome org, Matthias Clasen <mclasen redhat com>, gtk-devel-list gnome org, John Ehresman <jpe wingide com>, Colin Walters <walters verbum org>
- Subject: Re: Introspection API
- Date: Fri, 25 Feb 2005 13:53:18 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]