Possible Duplicate:
Why are compiled Java class files smaller than C compiled files?
Just out of curiosity I just compiled “Hello Worlds” in C, C++ and Java.
The Java class file comes out very lean at just 423B which I understand since the runtime isn’t included in the binary.
The C and C++ ones are 8.5K and 9.2K however.
Why are they so relatively big?
I always assumed stdio or iostream are linked at dynamically and don’t add to the size of the executable.
So where do all the kilobytes come from?
By looking at the hexdump I see that there’s a lot of padding, I guess for performance reasons. Why exactly is a binary format organized like that?
pmg’s link is very helpful!
Regarding the padding, I found it’s the aligning of the program’s segments to virtual memory page boundaries (4096 bytes) that causes it to be at least 8192 bytes.
Regarding the mach-o binary format (for OS X and iOS)
For best performance, segments should be aligned on virtual memory page boundaries—4096 bytes for PowerPC and x86 processors. To calculate the size of a segment, add up the size of each section, then round up the sum to the next virtual memory page boundary (4096 bytes, or 4 kilobytes). Using this algorithm, the minimum size of a segment is 4 kilobytes, and thereafter it is sized at 4 kilobyte increments.
I’ll do the research before asking next time 😉
This is a question of what you’re measuring. If it’s the raw executable size, this contains a great deal besides the code for
main().As we’re using shared dynamic libraries here, a great deal of the size will be accounted for by house-keeping data such as symbol tables, the global offset table and a description of the shared libraries to be linked against – the code of the shared libraries themselves is not in the binary.
The iostream library is a fairly large, and also has static initialisers – for instance to initialise
cout,cerr, andcinobjects. This is another thing that object file must contain.In reality, most of the extra size is not memory resident when the application runs.