Thread: overgrown .exe files

  1. #1
    Registered User
    Join Date
    Feb 2003
    Posts
    596

    overgrown .exe files

    I wrote this little program to help explain how mergesort works and noticed that if i compile it with Dev-C++ the executable is less than 77K, but compiled with the free Borland CPP Builder 5.5 the executable is over 154K -- literally twice as big.

    Does this Borland compiler always waste so much space?

    Why?

    How should I have written this differently to let Borland compile it without creating such a bloated file?

    (I already tried "using std::cin; using std::cout; using std::endl;" instead of "using namespace std;" but that didn't save any space at all -- with either compiler.)

  2. #2
    Novice C++ Programmer
    Join Date
    Nov 2003
    Posts
    96
    I'm not sure why this is but just to let you know, on my GCC compiler, it took up 411kb and with MSVC++ it took up 524kb.

  3. #3
    Registered User hk_mp5kpdw's Avatar
    Join Date
    Jan 2002
    Location
    Northern Virginia/Washington DC Metropolitan Area
    Posts
    3,817
    Using MSVC++ 6.0 (Sp 4 or 5, can't remember):

    Code:
                                    Release Mode     Debug Mode
    Default Options                 112 Kb           525 Kb
    C/C++ Options (minimize size)   96 Kb            NA
    As you can see, compiling under release/debug mode changes the size as does going into Project->Settings->C/C++ Tab->Optimizations->Minimize Size. That's with MSVC, chances are that your compiler also has options/tricks to reduce size of an executable.
    "Owners of dogs will have noticed that, if you provide them with food and water and shelter and affection, they will think you are god. Whereas owners of cats are compelled to realize that, if you provide them with food and water and shelter and affection, they draw the conclusion that they are gods."
    -Christopher Hitchens

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    The bulk of the space is taken up by
    - whether its a debug or a release build. Debug information takes up a lot of space, and release builds typically have minimal (or zero) debug information.
    - whether libraries are statically or dynamically linked. static libs take up space, whereas dynamic libs contain just stubs to load the actual library at run-time.
    - how well written the libraries are - do you get just the symbols you need or do you get a lot of 'useless' baggage as well.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Registered User
    Join Date
    Jan 2003
    Posts
    648
    I really don't know why people care so much about the sizes of their EXEs. If its 400 KB --> who cares? Its probably just loaded with all the OS stuff needed to make your program work. Just take a look at any game, it loads maybe up to 90 megabytes into RAM. Your little console application will load maybe 400 KB. When most computers nowadays have 256 MB RAM and up, who cares about an extra 200 KB, especially when your program is graphical.

    The only places where size matters is microcontroller programming and other small devices.

  6. #6
    vae victus! skorman00's Avatar
    Join Date
    Nov 2003
    Posts
    594
    Because if you don't worry about size, it get's hairy when you create a large application.

    Comparing games to other applications is not fair, being that games use massive ammounts of recources. And yes, we game designers to take the size of our .exe into considerations, and try to minimize it, along with all other files we use.

  7. #7
    Registered User
    Join Date
    Feb 2003
    Posts
    596
    Hmmm... I hadn't even tried it with MSVC but yes, I get the same 112/525 results with that one. I didn't even realize before now that there were two different build modes in MSVC. I've only used the build mode, so thanks for pointing that out.

    I read some of the Borland documentation (imagine that ) & found that there is a -O1 switch that compiles for "smallest possible code", but compiling with that gave exactly the same size (154,624) code.

    So apparently it's not debugging info that's loading it up. And, Salem, do you really think that Dev-C++ is compiling this little program with dynamic linking? All 3 exe's run equally well on a computer that has no compilers installed (or could it be finding dlls someplace in Windows' directory?).

    I guess it comes down to Salem's comment about 'excess baggage', which gets back to my original question. Is there a way to #include a subset of <iostream> to accomodate just cin and cout to save space?

    Oh, and Speedy5: you answered your own question in your last sentence. True, for this particular program it doesn't really matter much, but for AI programs for small robots with limited memory size definitely does matter. And anyway, to paraphrase a well-known saying, a billion here, a billion there, & pretty soon ...

  8. #8
    Registered User
    Join Date
    Feb 2003
    Posts
    596
    Anyway, to make a long story short, is this Borland compiler generally considered to be less efficient spacewise than other compilers?

  9. #9
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    I think you need to figure out all your compiler options, and what additional tools there are available.
    For example, if you're that worried by the size, then consider using an exe packing tool like UPX.

    Besides, once you've got the standard library linked into the executable, you can use if freely without increasing the size of your executable.
    Your exe might be a bloated 500KB with your simple "hello world", but the exe could be still only 600KB with your 10K line significant application and you'll be thinking you're getting a good deal on the size front.

    GCC derived compilers (Dev-C++ is one of them) should have these facilities which are available on pretty much any Unix/Linux based system.
    These are some size stats for compiling your program
    Code:
    # compile only
    $ g++ T_mergesort.cpp
    $ ls -l a.out
    -rwxrwxr-x       16870 Apr  8 22:02 a.out
    
    # compile with debug
    $ g++ -g T_mergesort.cpp
    $ ls -l a.out
    -rwxrwxr-x      125638 Apr  8 22:02 a.out
    
    # size tells you how big the real code is
    # strip removes all debug and symbol table information
    $ size a.out
       text    data     bss     dec     hex filename
       4531     856     300    5687    1637 a.out
    $ strip a.out
    $ size a.out
       text    data     bss     dec     hex filename
       4531     856     300    5687    1637 a.out
    $ ls -l a.out
    -rwxrwxr-x        7240 Apr  8 22:03 a.out
    # well over 100K of debug information removed from the executable
    
    # static linking of the run-time library
    # this adds a LOT of stuff to the executable
    $ g++ -static T_mergesort.cpp
    $ ls -l a.out
    -rwxrwxr-x     3566198 Apr  8 22:06 a.out
    $ size a.out
       text    data     bss     dec     hex filename
     700367   74565   25536  800468   c36d4 a.out
    
    # size contribution of just your own code
    $ g++ -c T_mergesort.cpp
    $ ls -l T_mergesort.o
    -rw-rw-r--        6460 Apr  8 22:23 T_mergesort.o
    $ size T_mergesort.o
       text    data     bss     dec     hex filename
       2735     528       8    3271     cc7 T_mergesort.o
    As you can see, there is a huge range of possible sizes depending on exactly how you compile and link the same piece of code.
    The only real way to compare one compiler against another (or different options for a compiler) is to compare what results you get with the last command shown above (the -c example).
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  10. #10
    Registered User
    Join Date
    Feb 2003
    Posts
    596
    Fascinating. Thanks Salem.

    I compiled the same source code with g++ on my school Solaris system & a.out was 13660 bytes, and then strip took it down to 3531 bytes.

    I tried it with g++ on my linux system & it came in at 3531 bytes immediately.

    So far, Dev-C++ comes up with the smallest .exe of the Windows-version compilers; a distant 75,776 bytes.

    Followed by the "release" version under MSVC 6.0 at 114,688 bytes, and then the Borland 5.5 at 154,624 bytes.

    These are all *supposedly* without any debug code. I don't see anything equivalent to strip in any of the Windows compilers' bin directories.

    So why are the Windows versions so drastically bigger than the Unix/Linux versions? Are the latter depending on the machine having code libraries to be linked at runtime, while the former are "stand-alone"?

  11. #11
    Registered User
    Join Date
    Mar 2003
    Posts
    13
    I don't know if there is any equivallent in Borland, but in VC++ you can do this. It makes most of my console apps less than 20k.

  12. #12
    Registered User
    Join Date
    Feb 2003
    Posts
    596
    Fascinating, Tybalt.

    That trick reduced the VisualC++ exe down from 112K to 6656 bytes.

    Would you (or anyone) care to explain what it actually did?

  13. #13
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > So why are the Windows versions so drastically bigger than the Unix/Linux versions?
    Look at what -static did to the size of my linux executable

    VC++ can dynamically link with libraries, you just have to tweak the right option
    I don't have it to hand at the moment to find out though.

    > Would you (or anyone) care to explain what it actually did?
    VC++ can edit files in binary mode. Load the "before and after" copies of the executable.
    You'll still see a lot of symbolic information in the original
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  14. #14
    Registered User
    Join Date
    Feb 2003
    Posts
    596
    >> VC++ can dynamically link with libraries, you just have to
    >> tweak the right option
    >> I don't have it to hand at the moment to find out though.

    This is part of Tybalt's "trick". Under project/settings/C-C++/code generation/use run-time library there is an entry for "Multithreaded dll". Applying this reduced the size of the .exe to 16384 bytes.

    But he also does: under project/settings/link/Project Options add an entry "/align:16384" (this number has nothing to do with the 16384 I mentioned above; purely coincidental). After adding that switch and re-compiling & building, the .exe is now only 6656 bytes.


    Do you know what that /align switch is doing?


    ---------------------------------------------------------------------------

    I did some more googling & found that there is a command-line switch for the Borland compiler, -tWCR that enables dynamic linking. Using that brings the Borland-compiled .exe down to 9,216 bytes. But now it only runs on a computer that has Borland's runtime library installed.

    On the other hand, the tiny VisualC++ .exe compiled with Tybald's approach seems to run on any Windows PC. Is it using a runtime library that is actually a part of Windows itself?

    -----------------------------------------------------------------------------

    >> VC++ can edit files in binary mode. Load the "before and
    >> after" copies of the executable.
    >> You'll still see a lot of symbolic information in the original

    I looked at them, but I'm not sure what I'm supposed to see. I see that there's a lot more code in the original, but we already knew that. And I have no idea what the code means.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Error opening files in a different dir
    By Ozzie in forum C++ Programming
    Replies: 3
    Last Post: 10-09-2008, 06:55 AM
  2. Working with muliple source files
    By Swarvy in forum C++ Programming
    Replies: 1
    Last Post: 10-02-2008, 08:36 AM
  3. Replies: 4
    Last Post: 07-24-2008, 09:02 AM
  4. Running the application (.exe) files on other PCs
    By csonx_p in forum Windows Programming
    Replies: 11
    Last Post: 06-11-2008, 09:31 PM
  5. Problem creating .exe files
    By Unregistered in forum C Programming
    Replies: 1
    Last Post: 03-22-2002, 02:25 PM