We should have a look at the new build system and add relevant optimisation flags to it (e.g. -Os, -O3, -mtune=pentium, etc.). For the sake of sanity, we should probably compile everything with the client base requirements in mind. Even if we know a package is only used for the server today, it might be used for the client in the future.
When I did the upgrade to FLTK 1.3.2 (bug 4461) and the adoptions to building FLTK with CMake, it turned out that -O3 did not work at all: I got the very strange error: /usr/lib/gcc/i686-apple-darwin8/4.5.3/../../../../i686-apple-darwin8/bin/ld: /usr/i686-apple-darwin8/sys-root/usr/lib/libfltk.a(Fl_Native_File_Chooser_MAC.mm.o) literal pointer section (__OBJC,__cls_refs) does not have is exactly one relocation entry for each pointer The solution was to switch to -Os instead. I actually like -Os better than -O3. http://www.gentoo.org/doc/en/gcc-optimization.xml says: "Using -O3 is not recommended for gcc 4.x". Apple uses -Os. The article on http://www.linux-mag.com/id/7574/ has done many tests (too many...?). At the end, they say "Generally speaking, the -Os level did worse than the others", but I'm not sure I fully agree. -Os did great in some tests. It reduces the compile time as well. Thus, -Os gets my vote as a standard/generic optimization flag. Then, we could build components such as vncviewer and SSH with a few different flags and see which one is best.
I'm growing a bit sceptical about -O3. -O2 seems to be what most people<tm> are using, and we and other seem to be hitting various bugs with -O3. We should consider switching to -O2 everywhere where we are currently using -O3.
As much as people bash gentoo, they make people build a lot of software from source, and here's what they say: > -O2 is the recommended default. -O3 is known to cause problems > when used system-wide, so we recommend that you stick to -O2.
I also prefer -O2 over -O3, but still thinks we should consider -Os.
More benchmarks of different O levels: http://www.phoronix.com/scan.php?page=article&item=gcc_47_optimizations&num=1
We've made a minor start of this work in the form of bug 4929.
Fedora has hidden this in their %cmake and %configure macros. We should probably do the same as it makes sure it isn't overlooked. Things that do not use cmake or automake still needs to be manually looked at though.
Bug 4929 implements just that. Which means that what's left on this bug is to check all the things that aren't covered by those macros. We also need a rebuild to have the new flags take effect.
