View mode: basic / threaded / horizontal-split · Log in · Help
December 18, 2010
executable size
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?
December 18, 2010
Re: executable size
"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.
December 18, 2010
Re: executable size
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!
December 18, 2010
Re: executable size
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.
December 18, 2010
Re: executable size
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
December 18, 2010
Re: executable size
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.
December 19, 2010
Re: executable size
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.
December 20, 2010
Re: executable size
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
December 20, 2010
Re: executable size
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.
December 20, 2010
Re: executable size
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home