home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 19156 < prev    next >
Encoding:
Text File  |  1993-01-03  |  2.7 KB  |  63 lines
  1. Path: sparky!uunet!paladin.american.edu!gatech!destroyer!ncar!noao!amethyst!organpipe.uug.arizona.edu!news
  2. From: dave@cs.arizona.edu (Dave Schaumann)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: [FAQ] size of executables ?
  5. Message-ID: <1993Jan3.212235.1338@organpipe.uug.arizona.edu>
  6. Date: 3 Jan 93 21:22:35 GMT
  7. References: <93003.004225RVK@psuvm.psu.edu>
  8. Sender: news@organpipe.uug.arizona.edu
  9. Reply-To: dave@cs.arizona.edu (Dave Schaumann)
  10. Organization: University of Arizona
  11. Lines: 49
  12. In-Reply-To: RVK@psuvm.psu.edu
  13.  
  14. In article <93003.004225RVK@psuvm.psu.edu>, RVK@psuvm writes:
  15. >How does one compile a c program so that the size of the
  16. >executable is as small as possible.
  17.  
  18. Most compilers have various switches that effect the size of the executable
  19. in various ways.  For instance, you may have switches to include information
  20. for debugging, or profiling.  Debugging information, in particular, can
  21. greatly inflate the size of the executable.  It doesn't really matter when
  22. you're trying to find a bug, but you should be sure that they're turned
  23. off when you're ready to put it into common use.
  24.  
  25. Additionally, compilers typically have a switch to turn on various
  26. optimization routines, which typically result in a smaller as well as
  27. faster executable.
  28.  
  29. There may also be switches that effect such things as the size of integers,
  30. which can also be used to reduce the size of the executable (but watch out--
  31. there's a lot of code out there that assume sizeof(int) == sizeof(int *)...)
  32.  
  33. Beyond that, about all you can do is try different compilers, which tend to
  34. vary quite a bit on the quality of code produced.
  35.  
  36. >I noticed that even a
  37. >trivial program like Hello.c  produces a huge executable,
  38.  
  39. I'm not sure what you consider "huge"...
  40.  
  41.   #include <stdio.h>
  42.   main() { puts("Hello, world") ; }
  43.  
  44. produces an executable of 24576 bytes in size on my machine (a Sun 4...)
  45. In my experience, programs compiled on a Sun tend to be larger than elsewhere,
  46. but not (completely) unreasonably so... 24+K might seem large for a program
  47. that simply sends a 13 byte string to the standard output, but as you
  48. surmize:
  49.  
  50. >perhaps due to the include files stdio.h etc.
  51.  
  52. This isn't quite correct... if you look at the contents of <stdio.h>, you'll
  53. see externs for lots of functions.  The code for these functions lives in
  54. the "standard library", which typically gets linked in to every program you
  55. compile.  Theoretically, there's no reason why the whole library has to be
  56. linked into your program when you only use a tiny piece of it... but it's
  57. much easier to do it that way, and given the fact that disk space and memory
  58. is fairly cheap, there's little motivation to do it just to save a few K off
  59. of a few small programs.
  60.  
  61. -- 
  62. Dave Schaumann            dave@cs.arizona.edu
  63.