Re: [Vala] GObject allocation / referencing... Why is so slow?

[Jan Hudec <bulb ucw cz>]

On Sat, Jan 15, 2011 at 19:58:37 +0100, Marco Trevisan (Treviño) wrote:
> Il giorno sab, 15/01/2011 alle 19.09 +0100, Jiří Zárevúcky ha scritto:
> > > Yes, it's not the same, but it's a similar implementation, using
> > > reference counting (it's not atomic, but if you use an sig_atomic_t ref
> > > variable, instead of the volatile int, you would get atomicity with no
> > > performance loss at all),
> >
> > Not true I believe. sig_atomic_t ensures atomicity on an entirely
> > different level.
> > It has nothing to do with multi-threaded programming.

No, it is not. There is no portable way currently (one is planned for C++0x
and while it includes a plain C variant, I don't know whether there are
currently any plans to adopt it for C), but GCC has it's own extension for
them, that is available for all supported platforms (see
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Atomic-Builtins.html)

So one can implement ref and unref as:

    typedef struct _Foo Foo;
    struct _Foo {
        int refcount;
        ...
    };

    Foo *foo_ref(Foo *foo)
    {
        __sync_add_and_fetch(&foo->refcount, 1);
    }

    void foo_unref(Foo *foo)
    {
        if(!__sync_sub_and_fetch(&foo->refcount, 1))
            foo_destroy(foo);
    }

> Mh, ok... So why using these features in Vala also when not using
> threads?

Vala normally simply uses functions provided by the selected runtime and
these functions are written so they work in threaded environment, because the
runtime may be used in such.

> However I don't think that an atomic add or fetch-and-add (or
> call them inc and dec-and-test) correctly used in plain C wouldn't cause
> all this performance gap.

Nor do I, but I'll try it with the above implementation substituted to your
test code.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>