Compiler: Size of generated executable file

[Nick Sabalausky]

"retard" <re at tard.com.invalid> wrote in message 
news:hiavkv$1meu$1 at digitalmars.com...
> Sat, 09 Jan 2010 19:44:07 +0100, grauzone wrote:
>
>> Nick Sabalausky wrote:
>>> "Ph" <romanua at gmail.com> wrote in message
>>> news:hia7qc$b5k$1 at digitalmars.com...
>>>> Why a generated file is so huge?
>>>> "Empty" program such as:
>>>>
>>>> int main(char[][] args)
>>>> {
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> compiled with dmd2 into file with size of  266268 bytes. Even after
>>>> UPX, it's size is 87552 bytes. Size of this code,compiled with
>>>> VS(yes,yes, C++), is 6 656 bytes. Compiler add's standard library  to
>>>> file, am i right? Is there some optimization which delete unused code
>>>> from file?
>>>>
>>>>
>>> That's not even a third of a megabyte, why does this keep getting
>>> brought up as an issue by so many people?
>>
>> Maybe most of them don't know that it's only constant overheads.
>
> Are you sure it's a constant overhead? I've written few thousands of
> lines in D and it always seems that if you port the same code to C++,
> Java or C#, not only is the constant overhead larger, the binaries seem
> to grow quite fast.
>
> E.g. if I link against some GUI lib, the hello world window+label grows
> to 2..5 MB. In Java the same app using Swing is still only a few
> kilobytes (label + window + procedure to close the app is 1.2 kB to be
> precise). Note that the Java app provides even better runtime reflection
> capabilities that D can. I would imagine a larger program that uses
> network, sound, graphics, and some other domain specific libraries would
> need a 50..100 MB binary .exe file when done in D.

I'd rather use an app that did a bunch of compile-time reflection than one 
that did a bunch of run-time reflection. And I think that 50..100 MB figure 
seems quite exaggerated unless you're packing all those art+sound assets 
into the exe itself (or if you're using that one GUI lib that's been known 
to result in really inflated exe's, forget which one that was...).