Re: [GObjectIntrospection] Cleaning up GIRepository

[Johan Dahlin <johan gnome org>]

On Tue, Aug 31, 2010 at 9:01 AM, Giovanni Campagna
<scampa giovanni gmail com> wrote:
> Il giorno lun, 23/08/2010 alle 09.10 -0300, Johan Dahlin ha scritto:
>> [not on gtk-devel, so CC me replies]
>>
>> On Fri, 20 Aug 2010 01:59:09 Giovanni Campagna <scampa giovanni gmail
>> com> wrote:
>> > First of all, sorry if this is not the correct mailing list but I did
>> > not find a more suited one (and Glib discussion happens here anyway).
>> >
>> > I started looking for GObjectIntrospection API recently and I've seen
>> > a lot of overlap with the original GObject/GType system.
>> > In particular, I would like to ask why the following were
>> > reimplemented (using the typelib and not run time type information):
>>
>> There are three primary reasons for not doing things within the GType system.
>>
>> A) GLib was up until last year moving very slowly, it seems that multiple year
>> processes were the norm for even the smallest functional additions.
>>
>> B) the GIRepsitory API reflects the internals of a binary typelib which will
>> be loaded from disk via mmap. It's intended to be used by multiple processes
>> within a gnome desktop and needs to use as little writable memory as possible.
>> I'm not sure how many bytes that needs to be allocated for a GObject,
>> but it's in the
>> multiple 100 byte range, while creating a GIBaseInfo only requires 44
>> bytes on 32-bit
>> systems.
>
> Well, if so much memory is required for a GObject, then making GObject
> more lightweight (possibly without signals and properties) would make
> sense.
> Secondly, little is gained by sharing the typelib, if the information is
> *also* contained in a different private writable memory area.

I'd welcome you to do the math, but I would be surprised if the savings
are less than in the MB range per application using the full gnome stack.
No such applications exists as far as I know, the best comparisons will
be old python bindings vs new ones, but they also improve/change several
other things that will make the memory requirement drastically decreased with
the new g-i based bindings.

>>
>> C) in many cases we want to avoid using the GType because it is not registered
>> at that point. Registering the GType means that we have to recursively register
>> the type and all its parents. Writing a lazy binding for dynamic languages like
>> python and javascript means that the type registration should only be done
>> when needed, eg such as when the class wrapper is accessed - usually when
>> the first instance of specific class is created.
>
> And why you would ever need information about a class which is not used
> and/or available to use?

For a library such as Gtk+ which provides hundres of types it is just
not efficient
to create wrappers as soon as they become available.


>> GObjectInfo needs to know about properties and signals which are also
>> available in the glib type system because annotations might override them.
>> For instance, we want to include array/transfer/direction metadata which
>> is only available in the typelib.
>
> Direction doesn't make sense for properties and I proposed how to encode
> array and transfer in GParamFlag.

When you get these modifications designed, implemented and included into glib
let me know so we can continue this discussion.

>> Registering an unref/ref method requires glib extensions as far as I understand.
>
> No, the (un)ref method is exposed in the GTypeValueTable.
>
>> The value transformation routines were added since the dynamic bindings for
>> objects such as GstMiniObject use gst_mini_object_set/get_value
>
> They should be able to use g_value_set_instance / g_value_peek_pointer,
> keeping gst_mini_object_*_value for C convenience.

Patches are welcome to move over to that scheme, remember that you'll
need update the gjs to use the new API as well.

> Why does the GIRepository API reflect the typelib? The typelib design
> should only be an implementation detail of libgirepository, that can be
> fixed at any time by recompiling gir files.

It is unfortunate that implementation details leaks up to the API,
but it is unavoidable in this case as the performance requirements made
it impossible to design a nice GObject based api.
I would love to be proved wrong in this case, but I don't have the time to
rewrite the whole API, update the bindings, the applications and benchmark
it against the current system to find out if it's worth it.

-- 
Johan Dahlin