On Mon, 20 Dec 2010 14:15:26 -0500, Jacob Carlborg <[email protected]> wrote:
On 2010-12-20 18:10, Steven Schveighoffer wrote:
On Sun, 19 Dec 2010 08:25:36 -0500, Gary Whatmore <[email protected]> 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
