December 18, 2010
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
"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
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
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
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
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
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
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
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
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