executable size

[Jacob Carlborg]

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.

> 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