On Wed, 2011-10-05 at 23:09 -0300, Damián Nohales wrote: > > El 05/10/11 22:07, bsquared escribió: > > Luca Bruno<lethalma...@gmail.com> writes: > > > >> On Wed, Oct 5, 2011 at 6:30 PM, > >> bsquared<bwcode4u-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote: > >>> > >>> 2. What can I do to optimize the generated c code in my tests? > >>> The generated code is 4x the size of original test code > >>> (test-couchdb-glib.c) as is the executable. > >>> > >> > >> For the C code, nothing. About the executable, optimize with -O3 (or -Os). > >> > > I was thinking there may be some kind of best practice to minimize the > > number of temp vars in the generated code. > > No, I don't think so, those temp variables appear because the manner in > which the Vala generate the code, the way to generate less code is to > modify the Vala compiler but not to optimizing your Vapi. > > You should not need to expect that Vala compiler generates a C code as > if you had written by hand as you should not expect the C compiler do > the same with the assembly code generated. >
While I agree that the temp variables have no impact on performance (they should be optimized out at -O1 not mentioning -O2 and -Os) they do have on debugging. Scrolling through list of ~60-70 variables named _tmpXYZ_ in backtrack so the do have some impact. I guess in long-term it would be beneficial to have Vala support in gdb but right now we don't. Regards
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
