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
_______________________________________________
vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
