Compiler: Size of generated executable file

[retard]

Mon, 11 Jan 2010 07:12:14 -0500, bearophile wrote:

> Walter Bright:
>> Optlink does this too. It's oooollldd technology, been around since the
>> 80's. Consider the following program:
> 
> Only now GCC is starting to do it, and only partially. If you compile
> that C example (3 files):
> 
> --- a.h ---
> extern int foo1(void);
> extern void foo2(void);
> extern void foo4(void);
> --- a.c ---
> #include "a.h"
> 
> static signed int i = 0;
> 
> void foo2(void) {
>  i = -1;
> }
> 
> static int foo3() {
> foo4();
> return 10;
> }
> 
> int foo1(void) {
> int data = 0;
> 
> if (i < 0) { data = foo3(); }
> 
> data = data + 42;
> return data;
> }
> 
> --- main.c ---
> #include <stdio.h>
> #include "a.h"
> 
> void foo4(void) {
>  printf ("Hi\n");
> }
> 
> int main() {
>  return foo1();
> }
> 
> All you find at the end is a binay that contains the compile of just:
> 
> int main() {
>     return 42;
> }
> 
> All other constants, variables and functions are absent. I'm sure it's
> not rocket science, but such things do actually improve performance of
> programs, sometimes in my tests up to about 15-25% (with the help of
> inlining too).

Just looking at the executable size (when compiled with dmc, the latter 
program is 30 kB and the first one is ~40 kB) makes it pretty clear that 
dmc/optlink does not optimize this. The same bloatness issue happens here 
- 10 kB extra just to potentially print "Hi!" - OMG. Unfortunately I'm 
not buying a windows / full dmc license to be able to objdump the 
executable so it's a bit hard to see what's inside it.