Re: [Vala] Vala vs Mono performance benchmark project

[Sandino Flores Moreno <tigrux gmail com>]

By using g_signal_emit you avoid having to parse the signal name to
retrieve the signal id.
However, the marshallers will not be affected at all.

2011/1/31 Aleksander Wabik <alex wabik gmail com>:
> Hi Pancake,
>
> I'll play with signals for a moment - will the marshallers be gone when
> using g_signal_emit()? I guess that they are generating much overhead...
>
> best regards,
>
> > on signals i can say that vala uses to call signals by name. vala should generate g_signal_emit() instead 
> > of g_signal_emit_by_name(). can you do a benchmark with this and tell us the performance boost?
> >
> > probably in type checking vala can do a better job at compile time.. but i should look some more code to 
> > talk..
> >
> > the ref/unref performance penalty can only be fixed with a garbage collector, or just delegating all these 
> > tasks to a separated thread, or use slices to alloc/free.. but this is more or less what a decent gc does.
> >
> > --pancake
> >
> > On Jan 30, 2011, at 7:55 PM, Aleksander Wabik <alex wabik gmail com> wrote:
> >
> > > Hi All,
> > >
> > > I've prepared a little benchmark measuring Vala object system
> > > performance ( http://gitorious.org/vala-object-benchmarks )
> > >
> > > - object creation and destruction
> > > - method, virtual method, interface method, signal, delegate, delegate
> > >  from a closure calling times
> > > - type checking
> > > - threading locks
> > >
> > > This benchmark is not intended to measure general performance (we have
> > > vala benchmarks in http://code.google.com/p/vala-benchmarks/ for this),
> > > but just to measure object system performance. From what I've seen:
> > >
> > > - type checking 2 times slower than in Mono
> > > - threading (locks) in vala beats mono easily - 19 seconds vs 50
> > >  seconds!!
> > > - object creation/destruction suck
> > > - setting/reading property or field beat Mono easily, but I think it's
> > >  the matter of compiler optimization; but in classes inheriting from
> > >  GObject setters are very expensive (due to issuing a signal)
> > > - calling methods, virtual methods, delegates, lambdas - vala beats
> > >  mono, but slightly
> > > - interface methods, signals - we really suck, and there's no excuse
> > >  for this. I guess that it can't be fixed in glib, but in dova...?
> > > - ref/unref - we really suck
> > > - weak ref/unref - we beat Mono easily, I guess that even if the
> > >  pointer assignment was not optimized out by a compiler we'd do this.
> > >  Mono is surprisingly bad at this.
> > >
> > > I guess that at least some of the vala performance drawbacks can be
> > > fixed in dova, as it's a total redesignment of the object system,
> > > true?
> > >
> > > If some of you would like to add some benchmarks / fix something in the
> > > existing ones, please do this, and have fun with the code that I made ;)
> > >
> > > best regards,
> > >
> > > --
> > > Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na
> > > serwerze hkp://keys.gnupg.net
> > >
> > > My public key with signature 1024D/E12C5A4C is on the server
> > > hkp://keys.gnupg.net
> > > _______________________________________________
> > > vala-list mailing list
> > > vala-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/vala-list
>
>
> --
> Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na
> serwerze hkp://keys.gnupg.net
>
> My public key with signature 1024D/E12C5A4C is on the server
> hkp://keys.gnupg.net
>
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list