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] |
----- 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] |