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

[Jan Hudec <bulb ucw cz>]

On Sun, Jan 16, 2011 at 03:00:06 +0000, Aleksander Wabik wrote:
> But I was not thinking of the speedup at the level of acquiring memory,
> but at the level of object construction. Let's say we have an object
> that has some fields. Now constructing such object requires allocating
> memory and then calling some very general function
> (G_type_create_instance), which initializes this memory, that is it
> calls proper constructors, and maybe some other things. My idea is:
> when the reference count drops to 0, don't delete object, but reference
> it in some global list instead, not at the allocator level, but at the
> object level. Let's make the constructor private, and let's create
> static function for obtaining new instances, that will call the
> constructor when the global list is empty, but it will just pop an
> object from that global list if it's not empty. Of course some
> initialization will have to be done, but still it will take less time.

You have to do it at the allocator level, because when you have lots of
instances of one type, but the program is now allocating other type, you have
to release the instances of the first (when doing it automatically).

It's what the slab cache (in kernel or in umem library) do. When you use an
object specific cache, you pass in function to initialize each object when
a slab is created and another function to finalize it when a slab is
released. Jeff Bonwick claims it helped Solaris significantly, because locks
are in the initial state when an object is released. Locks are abundant in
Solaris, but rare in most userland code and there are not many members with
similar properties. Well, in vala, two would have it -- the refcount and the
pointer to private part.

> I'm attaching two programs doing the same thing: allocate and destroy
> object in C++ and in Vala (non-gobject, but typed object). Vala is 3
> times slower.

Which clearly means there is some other problem. C++ is initializing the
object each time. A big difference is, that the C++ object only has the one
member -- no virtual method table, no refcount, no pimpl -- and it's
constructor is inlined (you even declared it inline). In vala, the
g_type_create_instance can't be inlined and needs to initialize the extra
members.

> But it probably could be many times faster if only the object was not
> created, but taken from some global LIFO and just initialized.

Dova could be made to either depend on umem, or the code generator to use it
when compiled with appropriate package.

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