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