Re: [Vala] Vala vs Mono performance benchmark project



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 <alex wabik gmail com> 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 <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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]