executable size

[Steven Schveighoffer]

On Mon, 20 Dec 2010 14:15:26 -0500, Jacob Carlborg <doob at me.com> wrote:

> On 2010-12-20 18:10, Steven Schveighoffer wrote:
>> On Sun, 19 Dec 2010 08:25:36 -0500, Gary Whatmore <no at spam.sp> wrote:
>>
>>> jovo Wrote:
>>>
>>>> Hi,
>>>> Today I compiled my old two module console program with d-2.50.
>>>> It uses only std.c.time, std.c.stdio, std.random and templates.
>>>> Compiled with -O -release, on windows.
>>>> Executable size (d-2.50): 4.184 kb.
>>>> Trayed with d-1.30: 84 kb.
>>>>
>>>> Is it expected?
>>>
>>> This is something you shouldn't worry too much about. Hard drives and
>>> system memory are getting bigger. 4 megabytes isn't that much when you
>>> have soon 4 terabytes of space. A single PC rarely has one million
>>> executables. So, keep writing more code. That's what the space is for.
>>
>> I hate this excuse, it's used all the time. The reality is that
>> executable size *does* matter, and it always will. Smaller programs load
>> and run faster.
>>
>> The other reality is that this is a toolchain issue, and not a language
>> or spec issue. With improved tools, this gets better, so it's not worth
>> worrying about now. When D gets full shared-library support, this
>> problem goes away.
>
> One problem that seems hard to solve in a good way is the module  
> constructors. Currently on Mac OS X with Tango when it's built as a  
> dynamic library all module constructors are run, regardless if they're  
> imported or not.

This is definitely a problem.  The issue I see mostly here is that Tango  
has many modules, specifically to allow trimming of unused code (another  
toolchain issue).

Two solutions that might work:

1. Mark the root module of the application (i.e. the one with main()).   
Then only initialize modules that are depended on by that module.  Where  
this fails is modules who define extern(C) functions (such as druntime),  
since you do not have to import those modules in order to call the  
functions.  I suppose modules with extern(C) declarations must also be  
marked as required.
2. Split the library into smaller libraries that would only be used when  
needed.

I'm not sure Phobos would have so much of an issue, because the number of  
modules is less.

One thing is for sure, this problem would be easier solved if we could  
decide things at link-time...

-Steve