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