www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - executable size

reply jovo <jovo at.home> writes:
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?
Dec 18 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"jovo" <jovo at.home> wrote in message news:ieit9a$2n58$1 digitalmars.com...
 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?

Yes. The runtime is currently built into the exe. With C/C++, the runtime is often stored separately so the exe files themseves end up a lot smaller, even though they rely on at least as much compiled code.
Dec 18 2010
next sibling parent jovo <jovo at.home> writes:
Nick Sabalausky Wrote:

 
 Yes. The runtime is currently built into the exe. With C/C++, the runtime is 
 often stored separately so the exe files themseves end up a lot smaller, 
 even though they rely on at least as much compiled code.
 
 

Thanks!
Dec 18 2010
prev sibling next sibling parent BLS <windevguy hotmail.de> writes:
On 18/12/2010 19:25, Nick Sabalausky wrote:
 "jovo"<jovo at.home>  wrote in message news:ieit9a$2n58$1 digitalmars.com...
 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?

Yes. The runtime is currently built into the exe. With C/C++, the runtime is often stored separately so the exe files themseves end up a lot smaller, even though they rely on at least as much compiled code.

Jovo compared d1 vs d2.. and here the difference is significant.
Dec 18 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-12-18 19:25, Nick Sabalausky wrote:
 "jovo"<jovo at.home>  wrote in message news:ieit9a$2n58$1 digitalmars.com...
 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?

Yes. The runtime is currently built into the exe. With C/C++, the runtime is often stored separately so the exe files themseves end up a lot smaller, even though they rely on at least as much compiled code.

Building the D runtime and the standard library as a dynamic library will get you the same executable size as a C executable, at least with D1 and Tango on Mac OS X. -- /Jacob Carlborg
Dec 18 2010
prev sibling next sibling parent torhu <no spam.invalid> writes:
On 18.12.2010 19:07, 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?

I'm guessing the new version of std.random pulls in almost all of the rest of phobos, directly or indirectly. This is common throughout phobos, and means that if you want a small executable, you have to stick with basically just the C core.c.* (or std.c.*) stuff. Unless you want to custom build Phobos, of course... If you really need a small executable, use Tango instead of Phobos.
Dec 18 2010
prev sibling parent reply Gary Whatmore <no spam.sp> writes:
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. - G.W.
Dec 19 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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. 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
Dec 20 2010
parent Jacob Carlborg <doob me.com> writes:
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
Dec 20 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/20/10, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 The reality is that
 executable size *does* matter, and it always will.  Smaller programs load
 and run faster.

Smaller programs, as in *less code*? Yes. But I really doubt that an application with the *exact same code* is faster if it's executable size shrinks. There are some apps that specialize in shrinking an executable size, I know that. I'd really like to see some performance comparisons of two copies of the same app, one with the original exe size, and the other processed by an exe shrinker.
Dec 20 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 20 Dec 2010 12:28:10 -0500, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 12/20/10, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 The reality is that
 executable size *does* matter, and it always will.  Smaller programs  
 load
 and run faster.

Smaller programs, as in *less code*? Yes. But I really doubt that an application with the *exact same code* is faster if it's executable size shrinks. There are some apps that specialize in shrinking an executable size, I know that.

No, I mean smaller exe size. It's well known that shrinking an app so portions of it (or all of it) fits into the cache can increase performance. If using common shared libraries, the OS only need load and store the library in memory once, so it can save memory and load more programs, or a program that consumes more memory during runtime can run faster without having to swap to disk. -Steve
Dec 20 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Dec 20 2010