This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fw: gcc 3.2 code bloating?


Miguel Ramírez <mramirez@iua.upf.es> writes:

> Example code:
> 
> #include <iostream>
> 
> int main( int argc, char** argv )
> {
> 
>  std::cout << "MinGW says hello to you" << std::endl;
> 
>  return 0;
> }
> 
> and its corresponding makefile:
> 
> CC=g++
> CFLAGS=-g -Wall
> LDFLAGS=
> PROGRAM=test
> OSEXECEXT=.exe
> 
> all: $(PROGRAM)
> 
> clean:
>  rm *.$(OSEXECEXT)
> 
> $(PROGRAM): test.cxx
>  $(CC) -o $@ $(CFLAGS) $<
> 
> Results of the build on Win2k with mingw3.2 ( gcc 3.2 ):
> 
> mramirez@APDIUA1 /c/mingw_tests
> $ ls -la
> total 639
> drwxr-xr-x    2 mramirez Administ     4096 Oct  9 07:30 .
> drwxr-xr-x  100 mramirez Administ    40960 Oct  9 07:22 ..
> -rw-r--r--    1 mramirez Administ      154 Oct  9 07:25 Makefile
> -rw-r--r--    1 mramirez Administ      135 Oct  9 07:29 test.cxx
> -rwxr-xr-x    1 mramirez Administ  1259581 Oct  9 07:29 test.exe
> 
> Results with Debian 3.0 with gcc 2.95 :
> SID@rivendel:~/exec_size$ ls -la
> total 16
> drwx------    2 mramirez iua            47 Oct  9 09:24 .
> drwx-----x   36 mramirez iua          4096 Oct  9 09:24 ..
> -rwx------    1 mramirez iua           154 Oct  9  2002 Makefile
> -rwxr-xr-x    1 mramirez iua         19124 Oct  9 09:24 test
> -rwx------    1 mramirez iua           135 Oct  9 09:24 test.cxx
> 
> Please note the executable size.
> 
> My hypothesis are the following:
> 
>     i) far too many templates instantiated due to including the
>     <iostream>

GCC 3.x comes with a much more compliant SC++L. Things that were plain
classes on GCC 2.x are now templates on GCC 3.x Your executable
includes debug info too. Use 'strip'.

>     ii) since the binutils are implemented on top of Windoze base
> services there's an overhead of about 20 k

MinGW links the SC++L and support libraries statically, while I'm
pretty sure that most Linux installations out there links them
dynamically. This is the main culprit of the difference.

OTOH, using toy programs to check if a compiler produces bloated
executables is... well... not very scientific.

> My training as programmer has conditioned me to think about big
> executables as generally evil ( bigger process = slower context
> switching ).

My _experience_ as a programmer tells me that, on almost all cases,
the overhead introduced by large executable code is negligible
compared against other factors. You'll better care about your
algorithms and general design.

> What can I do to alleviate this effect?

Hmmm... have you checked which program has the larger memory image
base? The statically linked GCC 3.x or the dynamically linked GCC 2.x?
(Both on the same OS, of course).

-- 
Oscar



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]