Big problem with Small programs

[kris]

kris wrote:
> Walter Bright wrote:
> 
>> kris wrote:
>>
>>> I have a helloworld.d program. I compile it on both Win32 and on 
>>> linux. On linux, the executable is 72KB whereas on Win32 it is 141KB. 
>>> Why is this?
>>>
>>> Turns out that D programs importing comprehensive Win32 D headers 
>>> will wind up with executable space occupied for *all* constants and 
>>> *all* struct initializers for the darned Win32 decls; where none of 
>>> them are actually used.
>>>
>>> That amounts to ~70KB of junk in the executable -- almost a full 100% 
>>> increase in size beyond what it should be.
>>>
>>> Does OptLink remove this? I've had no success with it. Walter? Can 
>>> you help with this?
>>>
>>> - Kris
>>
>>
>>
>> Try using enums instead of const variables, they don't take up any 
>> space in the object file.
> 
> 
> Thanks, but that makes only a dent in the overhead.
> 
> One might assume that dmd and optlink have no facilities to remove 
> unreferenced entities such as these? If so, doesn't this seem to be a 
> notable weak point in the toolchain?
> 
> Why is this not an issue with C/C++ ?
> 
> 1) C used true compile-time constants via #define. From your comment 
> above, it would appear enum is the equivalent in D, rather than const 
> int. Probably worth a note in the doc about that?
> 
> 2) C does not have struct inititalizers.
> 
> Why has this not come to light before? Well, the Phobos Win32 headers 
> are pretty darned slim compared with the real mcCoy. There's been a lot 
> of clamour for 'real' win32 headers for years. Now that we have them, 
> we're penalized for using 'em :p
> 
> Surely there must be some way for the linker to identify and discard 
> unused entities?
> 
> Another approach would be to make the win32 headers be .di files, such 
> that no obj files are generated. However, this breaks quickly whenever 
> one uses a struct requiring an initializer (link errors).
> 
> Enum is only a small partial resolution here, and we need to complete 
> the picture somehow. Any other suggestions, Walter? Can you tag the 
> structs internally somehow to make the linker discard the unused ones? 
> Can you explain exactly what's going on, such that others might be able 
> to suggest something?

For example (off the top of my head to get things rolling), what would 
be the ramifications of placing each struct initializer into its own 
data-segment? Would the linker manage to remove the unused ones then? If 
so, could a compiler flag be used to enable that, or could it be done 
behind the scenes?

Other suggestions?