There are other relevant reasons to choose Vala over C#, but speed is not one of them. :)
This is... very sad. JIT is cool, because it helps to get rid of performance problems introduced by some features of OOP, but if we are compiling to C, should we not try to solve these problems on another level? I mean, that JIT can be used to generate lots of non-reusable code at the runtime. This non-reusable code is fast. But handwriting such non-reusable code by the programmer should of course be discouraged. On the other hand, it should be strongly encouraged to generate such code by the compiler. Why use g_type_create_instance()? Yes, it's helluva reusable, you can create any typed class instance with it. And lose the performance contest badly. But the compiler (valac) COULD generate a function for each class, a function that would create instance of such class by (for example) just allocating memory and memsetting it with an "newly created class of such type" template. We need per-class specific creation functions anyway, they're called constructors. Will the code bloat? Certainly yes, but when running C# program, memory usage is also high. There are other things that could be fixed in some "ideal OO profile for vala". Why check for object non being null at the entry of the function? I know that we have --disable-assert, but on the other hand, when compiling with experimental non-null we SHOULD disable these assertions in all functions, because at the compile time the places where the null (or possibly null) value is assigned would be enumerated. These assertions could be placed there and only there. But let's say that this is a matter of optimization, not a matter of general design. Other thing: why delete objects when refcounting drops to 0? Let's maintain a queue of some size (maybe tweakable by a class attribute) of objects that will be just re-initialized when operator new is called? This is a matter of general design. Other thing: why do we call [CLASS]_GET_INTERFACE even on objects of class known at compile time? This is also a matter of optimization, not the general design, so let's say that it's less important. Other thing: why access private data through a pointer? Oh, I read rationale for this architecture somewhere in glib manual, but on the other hand, we can not enforce 'protected' on C level. Maybe private can be spared too? General design, although impact on performance should not be high. Other thing: signals. Did someone measured their performance? I did once, its AWFUL! Why? Well, here we also are using highly reusable, and very slow code. Signals are referenced by name (yes, string!), signals get complicated marshallers for their parameters... I don't know if it can be fixed easily in glib profile, but in such language like vala the signal could be implemented as a list of function pointers! I bet that any JIT, in C# or in Java (when java will finally support events/signals) will beat glib signals easily. A matter of general design. Well. My three pennies this time look like a ton of scrap metal. best regards, -- Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na serwerze hkp://keys.gnupg.net
Attachment:
signature.asc
Description: PGP signature