Wow! Thats good news! Will test it tomorrow :) Another optimization that can bring a 1% extra can be to define ref and unref in .h as static inline functions. But thats something the compiler must optimize.
On 31/01/2011, at 20:23, Aleksander Wabik <[email protected]> wrote: > Hi, > >> 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? > > I added new benchmark by manually hacking generated C code. The > performance gain is significant, about 18%. > > call_signal_typed: 10,473 <----- this it in vala-generated signal > invoking benchmark > > call_signal_by_reference_typed: 8,544 <---- this is in the hacked code > > I've committed the patch that should be applied to the generated C > code, and the instructions what to checkout, how to generate C code, > how to apply a patch, and how to build benchmark application from the > patched C code. The patch itself is very hackish, but does the job. > > The commit containing this patch was tagged with name: > 'check_g_signal_emit_vs_g_signal_emit_by_name_performance.patch' > > It can also be reviewed here: > http://gitorious.org/vala-object-benchmarks/vala-object-benchmarks/commit/e90927e4cb1d65ce692d295817d25cafc789c85f > > best regards, > >> 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
