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

[Jiří Zárevúcky <zarevucky jiri gmail com>]

2011/1/15 Aleksander Wabik <alex wabik gmail com>:
> > There are other relevant reasons to choose Vala over
> > C#, but speed is not one of them. :)
>
> This is... very sad. JIT is cool, because it helps to get rid of
> performance problems introduced by some features of OOP, but if we are
> compiling to C, should we not try to solve these problems on another
> level?

Maybe, if it is worth the effort.

> There are other things that could be fixed in some "ideal OO profile
> for vala". Why check for object non being null at the entry of the
> function? I know that we have --disable-assert, but on the other hand,
> when compiling with experimental non-null we SHOULD disable these
> assertions in all functions, because at the compile time the places
> where the null (or possibly null) value is assigned would be
> enumerated. These assertions could be placed there and only there. But
> let's say that this is a matter of optimization, not a matter of
> general design.

Optimization.

> Other thing: why delete objects when refcounting drops to 0? Let's
> maintain a queue of some size (maybe tweakable by a class attribute) of
> objects that will be just re-initialized when operator new is called?
> This is a matter of general design.

This is more interesting, but then we could simply make it possible to
use a garbage collector in Vala programs to achieve yet better
results.

> Other thing: why do we call [CLASS]_GET_INTERFACE even on objects of
> class known at compile time? This is also a matter of optimization, not
> the general design, so let's say that it's less important.

This is also a matter of how we handle implementing interfaces.
Both optimization and general design problem.

> Other thing: why access private data through a pointer? Oh, I read
> rationale for this architecture somewhere in glib manual, but on the
> other hand, we can not enforce 'protected' on C level. Maybe private
> can be spared too? General design, although impact on performance
> should not be high.

Dova profile prohibits non-private fields entirely. Let's do the same
in GLib profile (except bindings) and problem solved, we don't have to
care about the distinction. On the other hand, the way Dova profile
accesses object data is even less direct than GObject way. I'd like to
see what the actual performance difference is.

> Other thing: signals. Did someone measured their performance? I did
> once, its AWFUL! Why? Well, here we also are using highly reusable, and
> very slow code. Signals are referenced by name (yes, string!), signals
> get complicated marshallers for their parameters... I don't know if it
> can be fixed easily in glib profile, but in such language like vala the
> signal could be implemented as a list of function pointers! I bet that
> any JIT, in C# or in Java (when java will finally support
> events/signals) will beat glib signals easily. A matter of general
> design.

Changing this in GObject is imo not possible.

> Well. My three pennies this time look like a ton of scrap metal.

:)