Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jovo | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jovo | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to jovo | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gary Whatmore | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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
|
Copyright © 1999-2021 by the D Language Foundation