Release Build
Creating the Release build
When the debug build of an executable is made, there is lot of overhead associated with the debug information. The executable is slow and large in size because the debugging information embedded into the executable. When the final product is shipped to the customer, the debugging information should be removed from the executable. This is done simply by not including the -g flag at compile time.
Removing the Debug information
Instead of recompiling the application without the -g flag, the debug information can also be removed using the strip utility. strip simply removes the debug information that compiler has embedded in the executable.
The syntax of strip utility is strip <filename>.
$ gcc -g hello_world.c -o hello_world$ ls -l hello_world-rwxr-xr-x 1 achintm apon 5549 Oct 21 14:31 hello_world$ strip hello_world$ ls -l hello_world-rwxr-xr-x 1 achintm apon 2788 Oct 21 14:33 hello_worldNote that the size of the hello_world program has reduced from 5549 bytes to 2788 bytes by using strip. Even if the -g flag is not used, there is some debug information still present in the executable.
$ gcc hello_world.c -o hello_world$ ls -l hello_world-rwxr-xr-x 1 achintm apon 4561 Oct 21 14:40 hello_world$ strip hello_world$ ls -l hello_world-rwxr-xr-x 1 achintm apon 2788 Oct 21 14:41 hello_worldHere we have not used the -g flag while compiling hello_world.c. The size of the executable hello_world is 4561, smaller than the executable which was created using -g flag. But strip still reduced the size of the executable to 2788. Therefore it is a good idea to use the strip utility on the final executable even if you don't use the -g.
Compiler Optimization
GCC also provides the provision for the optimization in different number of ways. In order to allow the compiler to optimize the code in its way some options/flags have to be specified to gcc while compiling the program. The optimization level is specified with -OLEVEL where LEVEL is a integer number between 0 to 3. If you use multiple -OLEVEL options, with or without level numbers, the last such option is the one that is effective. Here is the description of the various optimisation flags that can be used with gcc:
-O0 Do not optimize. This is the default flag which instructs to disable any optimization.
-O1 This level turns on the most common forms of optimization that do not require any speed-space tradeoffs. With this option the resulting executables should be smaller and faster than with -O0. The more expensive optimizations, such as instruction scheduling, are not used at this level. Compiling with the option -O1 can often take less time than compiling with -O0, due to the reduced amounts of data that need to be processed after simple optimizations
-O2 Nearly all supported optimizations that do not involve a space-speed tradeoff are performed. Loop un-rolling and function inlining are not done, for example. As compared to -O, this option increases both compilation time and the performance of the generated code.
-O3 Optimize yet more. This turns on everything -O2 does, along with also turning on -finline-functions. This would try to convert functions into inline functions. Therefore this may increase the speed of the resulting executable, but can also increase its size
Optimizing compilation takes somewhat more time, and a lot more memory for a large function. Without -O, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. The compiler tries to reduce code size and execution time.
Enabling -O flag might result in some other flags also getting enabled e.g. when you enable -O3 -finline-functions also gets enabled. Also, if -O is specified, the two options -fthread-jumps and -fdefer-pop are turned on. On machines that have delay slots, the -fdelayed-branch option is turned on. For those machines that can support debugging even without a frame pointer, the -fomit-frame-pointer option is turned on. On some machines other flags may also be turned on.