Thanks for the explanation. Still I do remember seeing a comparison where vala code performed better, but the c code it was compared to might have been not as well-written as the vala code, I don't know about that. Unfortunately I do not remember exactly where I saw this (it is actually quite a while ago, possibly a year) but it might have been on the vala wiki or some other vala related site.
PCMan <[email protected]>schreef: >On Thu, Jun 28, 2012 at 9:29 PM, Joost van der Hoff ><[email protected]> wrote: >> I heard the Vala compiler actually generates more efficient C-code than the >> average C-programmer sometimes. This could be the reason your C code uses >> more memory, though if that is the case the difference should be quite small. >> >> Otherwise you could check the Vala-generated C code and see if it is similar >> enough to your code to compare the two looking for subtle differences. This >> might help you find the leak. >> >> 2noob2banoob >> >> Stephen Smally <[email protected]>schreef: >> >>>Hi guys, just to try, i wrote a C version of Lxde Control Center >>>(attached), it works, but uses more Ram than the Vala one, how's >>>possible? maybe there are some memory leaks (i'm not expert with >>>pointers), can anybody take a look? >>> >>>Stephen Smally > >Not really. The C code Vala generates is never optimized. >It generates much redundant code and relies heavily on C compilers to >optimize the generated code. For gcc this is not a real problem as it >indeed does a great job optimizing C code. In an era that compilers >are good enough, readability of source code sometimes is more >important than optimization. >Vala generated C code is slightly more inefficient than hand-written C code. >However it's good enough in most cases. >If you really need to make sure that some piece of code is in an >optimized state, write it in plain C. It's easy for Vala programs to >call C functions. >The only problems of Vala I see now are various errors in vapi binding >files and sometimes it generates wrong code. That's the source of >hard-to-discover bugs. >Otherwise it's a nice tool balancing ease of development and runtime >performance. >Believe me, doing OO programming with plain C/Glib and writing >hard-to-read code won't make the programs less buggy. Doing reference >counting manually is not interesting at all. >Try it and you'll believe what I say. :-) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
