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+
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:
> 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);
It's much more competitive to have:
value.g_type = G_TYPE_OBJECT;
value.data.v_pointer = object;
But currently that isn't considered legitimate usage of GValue API
at the present time.
gtk-devel-list mailing list