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

[Marco Trevisan (Treviño) <mail 3v1n0 net>]

Il giorno ven, 14/01/2011 alle 14.17 -0500, Jonathan Ryan ha scritto:
> First of all your "Objects" aren't GObjects, you need to
>
> private class TestObject : Object
>
> for them to be GObjects. The generated code is much different.

Yes I know that, but I meant using the Gobject vala profile... Or GType
anyway: however I guess that making my object being a subclass of
GLib.Object would reduce the performances any more (yes, I've just
tried; the measured times goes up to: 5.753s, 60.585s and 129.765s [so,
doubled again] and in the three tests above).

Plus, In this simple case using a [Compact] TestObject class and owned
objects maybe would help a lot, but this is not possible in every case,
and as stated before: OO-programming needs often to allocate many
complex objects, more than using methods over them...

> Second of all each iteration your object is being unreferenced. If do 
> you a profile, ~6% of that time is being spent unreferening the
> object. 

Yes I know, and I forced for that... I wanted to know how the reference
counting was influencing in the performance, but also the C version does
it (also if using less checks)... However Valgrind gives us nice stats.

Setting N = 100,
For GLib vala profile (using Object superclass:
        total heap usage: 778 allocs, 395 frees, 395,890 bytes allocated (!!!)
For GLib/GType vala profile:
        total heap usage: 761 allocs, 389 frees, 394,975 bytes allocated (!!!)
For dova vala profile:
        total heap usage: 225 allocs, 207 frees, 10,250 bytes allocated
For C:
        total heap usage: 102 allocs, 102 frees, 3,232 bytes allocated

So, it's quite easy to see where's the performance lost

> This could also expalin the differences in time considering C#'s
> garbage 
> collector does not use reference counting as does GObject, so it's 
> problaby not deallocating those new objects you create them each
> loop, 
> which would increase the time signifiacantly.

Yes I thought the same too... Java or C# simply would not free any data
per-iteration, so the cpu time should be less (but maybe with more
memory usage)

> You're C code doesn't use GObject, so why are you comparing it to 
> GObject? GObject provides more functionality than your code,
> including 
> thread safe reference counting, which is also taking time up in the
> profile.

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), as Vala should do without using GType/GObject.
Take it as an ideal basic implementation of that class using
ref-counting (without ref-counting, maybe we could get better
performances too).

PS: All this with GLib 2.26.1