On 2010-12-20 18:10, Steven Schveighoffer wrote:
> On Sun, 19 Dec 2010 08:25:36 -0500, Gary Whatmore <no@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.

> Array appending performance/invalidity used to be one of the most common
> negatives cited on D. Now, nobody talks about it because it's been
> fixed. You will see the same thing with exe size once D uses shared libs.
>
> -Steve


-- 
/Jacob Carlborg

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

> On 2010-12-20 18:10, Steven Schveighoffer wrote:
>> On Sun, 19 Dec 2010 08:25:36 -0500, Gary Whatmore <no@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