Compiler: Size of generated executable file

[grauzone]

Walter Bright wrote:
> grauzone wrote:
>> Walter Bright wrote:
>>> grauzone wrote:
>>>> (The final executable is almost twice the size as the D2 one too, 
>>>> although it's questionable how much of the additional size is due to 
>>>> templates.)
>>>
>>> Finding out why an executable is large is as easy as compiling with 
>>> -L/map on Windows and -L-map -Lfoo.map on Linux/OSX, and then 
>>> examining the resulting map file which will tell you each and every 
>>> symbol in the executable and how large it is.
>>
>> Yes, but making sense out of the raw data is another thing.
> 
> What's hard about "function foo is in the executable, and consumes 421 
> bytes"?

If an executable has > 10000 symbols, it's hard to find out what's 
actually causing overhead. If you have a script, that categorizes symbol 
types by demangling the symbol names and creates statistics based on 
this or so, please post.

> All a linker does is concatenate the bytes of your generated code 
> together from the various obj files and write it out. There's no magic 
> going on.

If it's so simple, then why does OPTLINK fail so hard? I can only guess 
how many people are turning away from D just because they have to deal 
with OPTLINK's inability to deal with COFF. They end up trying to 
compile libraries with dmc etc., just to get it linked.