[ros-dev] Optimization Proposal

Thomas Weidenmueller w3seek at reactos.com
Wed Jan 4 02:18:51 CET 2006

Alex Ionescu wrote:
> - -O2 makes the compiler do additional checks. For example, gcc will NOT
> detect uninitialized variables unless -O2 is being used, even though
> they are a very important programming bug. Apart from finding more bugs,
> it also makes trunk compilable. Right now, I see at least two commits by
> Thomas or others being made every week in order to fix some code which
> used unitinialized variables (I myself have been guilty of this). This
> means that some of us, like Thomas, have to constantly fix other
> people's mistakes.
> - -O2 means less last-minute blockers. Because we release in -O2 but
> almost never build it like that, this creates a big problem for people
> like Andrew or Brandon, which handle the release process and do testing.
> Because the -O2 build gets less testing coverage, it is very possible
> for a critical bug to be in ROS for a month before anyone notices it at
> release time, in which case we will all have to scramble to find a fix
> for it.
> - -O2 will not undefine DBG or change anything else in the code. All the
> advatanges, extra error checking and assertions of the DBG =1 build
> would remain.
> - -O2 builds are much faster, greatly helping testing speed.
> - -O2 builds are much more likely to bring up race conditions and other
> important timing bugs we need to watch out for.
> - -O2 means easier debugging. This point is really important because
> until I realized how true it was, I didn't want to bring this up. Here
> is a pseudo(but real) disassembly of something I've seen in my dbg = 1
> kernel binary while debugging:

I've been building with -O3 exclusively for most of these reasons for a
long time. I've had to fix countless bugs/warnings in the past that were
only exposed with optimizations enabled. So I really do support a switch
to -O2/3 although people with slower development machines might not like
this. Depending on the hardware and OS the build time might increase
dramatically. However, at least GCC 4.0.x still has the sibling call
optimization bug, so -fno-optimize-sibling-calls should be used at least
for now. I'm not sure if it's been fixed in the 4.1 branch.

- Thomas

More information about the Ros-dev mailing list