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.
