This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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

Re: gcc code bloat



----- Original Message -----
From: <andy@softbookpress.com>
To: <crossgcc@sources.redhat.com>
Sent: Tuesday, December 05, 2000 2:20 PM
Subject: gcc code bloat


> I have an armv4l  box running Linux with gcc 2.95.1
> I see a rather significant size increase when compiling  my C++ code with
> gcc ( g++ to be exact)  even with -02 optimization level vs MetroWerks C++
> on the Mac
> Is there anything I can do about it ?
> The code uses templates, namespaces  and exceptions.

Comment 1) C++ executables are often much larger than C executables; this is
normal. So if you need small executables, either: a) use C instead of C++,
and/or b) do not use the C++ features that tend to bloat executable images
(e.g., iostreams, exception handling, various STL classes, etc.).

Comment 2) I suspect that the executable images you're producing with
MetroWerks C++ are smaller because they are linking with the C++ libraries
dynamically (i.e., at runtime). IOW, the C/C++ runtime libs are actually
dynamic link libraries (DLLs), and your program is loading these DLLs into
memory -- and linking with them -- at runtime. To verify this, rebuild your
executable images with MetroWerks C++ using only static linking and then
recheck the sizes of the executables.

Comment 3) If your classes have many/large inline functions, and these
functions are being used in multiple translation units, this can sometimes
increase the size of the final executable image. [Example: Writing
Java-style C++ code is a common cause of image bloat -- i.e., a class's
member functions are implicitly defined as "inline" because the member
functions are being defined within the class's definition block:

    class X {
        ...
        // Java-style function definition
        void  f ( void )
        {
            // many lines of code that define
            // function f() here...
        }

        void  g ( <etc> )
        {
            // many lines of code that define
            // function g() here...
        }

        etc...
    };

--end example]

Note that the compiler may or may not choose to inline a member function
that's declared (implicitly or not) as 'inline'. If the compiler does *not*
inline the function, it will be generated using static linking -- which
means there is one member function definition per translation unit.
Consequently, the resulting executable image can end up with multiple
definitions a given "inline" function. [Also note that you cannot "force"
the C++ compiler to inline a function. The 'inline' directive is only a
suggestion to the compiler -- i.e., you're giving your blessing that the
compiler may inline the specified function if it wants to do so...]

Comment 4) Have you tried stripping the symbols (man strip) out of the
executable images?

Comment 5) Make sure the debugging options (e.g., -g) are not used when you
compile the code.


Jim



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


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