www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Executable size

reply "Elbert Lev" <elbertlev hotmail.com> writes:
I'm a hardcore C++ programer. Last night downloaded D and read a few pages
about ideas behind it. And I agree  with them! Them I automatically compiled
supplied examples. All worked, but I was supprised by the produced
executable sizees. A very basic console application is 60-70 kb. explain me
why?

I suspect, that this happens because of static linking to runtime library.
But may be I'm wrong and bloated executable is just a price you have to pay
for great features, D offeres.  I understand that now the memory/disk space
is cheap, but...
May 02 2004
next sibling parent imr1984 <imr1984_member pathlink.com> writes:
Id say that yes, its just because all D programs have to linked statically with
the runtime. C++ is so popular that the run time comes in dlls (or the like)
with the operating system.

In article <c730ri$1di8$1 digitaldaemon.com>, Elbert Lev says...
I'm a hardcore C++ programer. Last night downloaded D and read a few pages
about ideas behind it. And I agree  with them! Them I automatically compiled
supplied examples. All worked, but I was supprised by the produced
executable sizees. A very basic console application is 60-70 kb. explain me
why?

I suspect, that this happens because of static linking to runtime library.
But may be I'm wrong and bloated executable is just a price you have to pay
for great features, D offeres.  I understand that now the memory/disk space
is cheap, but...

May 02 2004
prev sibling next sibling parent "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Elbert Lev" <elbertlev hotmail.com> wrote in message
news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few pages
 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain

 why?

It's an overhead (needed for GC) that seems extremely large for small trivial programs such as those presented in the examples. This overhead however is static and does not grow with the size of the program. Thus, a program of significant value or size (comercially viable programs [opensource or otherwise]) will not be affected by the menial overhead imposed.
 I suspect, that this happens because of static linking to runtime library.
 But may be I'm wrong and bloated executable is just a price you have to

 for great features, D offeres.  I understand that now the memory/disk

 is cheap, but...

May 02 2004
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Elbert Lev schrieb:

 I'm a hardcore C++ programer. Last night downloaded D and read a few pages
 about ideas behind it. And I agree  with them! Them I automatically compiled
 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain me
 why?

Because a very basic C++ application compiled with DigitalMars compiler is also the same size, a C application perhaps 15 kilobytes smaller. If you are used to Microsoft compilers: the Microsoft C runtime is distributed with Windows. Some other compilers, like LCC and MinGW also use it, and thus can have very small footprint on executable. But since DigitalMars compilers use their own C runtime, it was decided that it should be linked in, so that compatibility is not sacrificed. In fact, it might be possible to make DigitalMars compilers work with the MS C runtime DLL, though there's probably not too much sense at the moment. The current D runtime is built upon C runtime and pulls a significant portion of it in. This is quite wise since C standard library is a part of the D standard library specification anyway, and would likely be pulled in by some other library or part of application anyhow.
 I suspect, that this happens because of static linking to runtime library.
 But may be I'm wrong and bloated executable is just a price you have to pay
 for great features, D offeres.  I understand that now the memory/disk space
 is cheap, but...

You are right, on both points. Besides, size matters even more for big applications than for small ones, and i suspect D executables grow significantly more slowly than C++, because most of memory management code disappears, along with most try/finally frames automatically generated by the C++ compiler. So i would say, D features rather save space than sacrifice it, on the large count. -eye
May 02 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Elbert Lev" <elbertlev hotmail.com> wrote in message
news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few pages
 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain

 why?

 I suspect, that this happens because of static linking to runtime library.
 But may be I'm wrong and bloated executable is just a price you have to

 for great features, D offeres.  I understand that now the memory/disk

 is cheap, but...

In general, a D executable will be the same size as a C++ one plus about 40k for the garbage collector code. However, as Ilya pointed out, D code should grow slower than C++ code.
May 02 2004
next sibling parent reply "Bruno A. Costa" <bruno codata.com.br> writes:
Walter wrote:

 
 "Elbert Lev" <elbertlev hotmail.com> wrote in message
 news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few
 pages
 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain

 why?

 I suspect, that this happens because of static linking to runtime
 library. But may be I'm wrong and bloated executable is just a price you
 have to

 for great features, D offeres.  I understand that now the memory/disk

 is cheap, but...

In general, a D executable will be the same size as a C++ one plus about 40k for the garbage collector code. However, as Ilya pointed out, D code should grow slower than C++ code.

There is some way to completely disable GC, avoiding this extra code? Reading the especs I learnt about gc.disable(), but I'm no sure if it avoid the GC code. Thanks, Bruno.
May 03 2004
parent "Walter" <newshound digitalmars.com> writes:
"Bruno A. Costa" <bruno codata.com.br> wrote in message
news:c75dtg$1rub$1 digitaldaemon.com...
 There is some way to completely disable GC, avoiding this extra code?
 Reading the especs I learnt about gc.disable(), but I'm no sure if it

 the GC code.

Sure. Write your own stub functions in std.gc to prevent the library ones from being linked in.
May 15 2004
prev sibling next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Walter wrote:

 
 "Elbert Lev" <elbertlev hotmail.com> wrote in message
 news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few
 pages
 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain

 why?

 I suspect, that this happens because of static linking to runtime
 library. But may be I'm wrong and bloated executable is just a price you
 have to

 for great features, D offeres.  I understand that now the memory/disk

 is cheap, but...

In general, a D executable will be the same size as a C++ one plus about 40k for the garbage collector code. However, as Ilya pointed out, D code should grow slower than C++ code.

Is there a fundamental reason why the garbage collector code has to be statically linked?
May 03 2004
parent "Walter" <newshound digitalmars.com> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c75ivg$265a$1 digitaldaemon.com...
 Is there a fundamental reason why the garbage collector code has to be
 statically linked?

No. I just happen to dislike runtime-library-as-dll because of the DLL hell problems.
May 15 2004
prev sibling parent reply "Lev Elbert" <elbertlev comcast.net> writes:
OK! Statically linked run-time library is fine for a big program, but there
are cases when one needs a set of utilities (like Unix text utilities), or
small and simple GUI programs. Why not to have dll (so) for dynamic linking
and the developer can choose which stile to use? I do not think that this is
hard to do, or dlls will create problems.



"Walter" <newshound digitalmars.com> wrote in message
news:c7521u$1dnt$2 digitaldaemon.com...
 "Elbert Lev" <elbertlev hotmail.com> wrote in message
 news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few


 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain

 why?

 I suspect, that this happens because of static linking to runtime


 But may be I'm wrong and bloated executable is just a price you have to

 for great features, D offeres.  I understand that now the memory/disk

 is cheap, but...

In general, a D executable will be the same size as a C++ one plus about

 for the garbage collector code. However, as Ilya pointed out, D code

 grow slower than C++ code.

May 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I'd be more interested in a super-compact GC, possibly with an incredibly
dumb/slow implementation.

Since a great many utilities are run-briefly things, it would not pose a problem
if there was simply no GC. I'd like to be able to select a phobos-light.lib.

"Lev Elbert" <elbertlev comcast.net> wrote in message
news:c76cic$ci0$1 digitaldaemon.com...
 OK! Statically linked run-time library is fine for a big program, but there
 are cases when one needs a set of utilities (like Unix text utilities), or
 small and simple GUI programs. Why not to have dll (so) for dynamic linking
 and the developer can choose which stile to use? I do not think that this is
 hard to do, or dlls will create problems.



 "Walter" <newshound digitalmars.com> wrote in message
 news:c7521u$1dnt$2 digitaldaemon.com...
 "Elbert Lev" <elbertlev hotmail.com> wrote in message
 news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few


 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain

 why?

 I suspect, that this happens because of static linking to runtime


 But may be I'm wrong and bloated executable is just a price you have to

 for great features, D offeres.  I understand that now the memory/disk

 is cheap, but...

In general, a D executable will be the same size as a C++ one plus about

 for the garbage collector code. However, as Ilya pointed out, D code

 grow slower than C++ code.


May 04 2004
next sibling parent "Lev Elbert" <elbertlev comcast.net> writes:
Since a great many utilities are run-briefly things, it would not pose a

 if there was simply no GC. I'd like to be able to select a

True in most cases. For example grep. Usually you run it over a 100 files, but then you run it over the directory with half a million files... But phobos-light.lib is certainly another option. Also take into account that dll version of phobos is nothing more then "repackaging" of existing code. While light version is full rewrite. "Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c786a3$2q2$1 digitaldaemon.com...
 I'd be more interested in a super-compact GC, possibly with an incredibly
 dumb/slow implementation.

 Since a great many utilities are run-briefly things, it would not pose a

 if there was simply no GC. I'd like to be able to select a

 "Lev Elbert" <elbertlev comcast.net> wrote in message
 news:c76cic$ci0$1 digitaldaemon.com...
 OK! Statically linked run-time library is fine for a big program, but


 are cases when one needs a set of utilities (like Unix text utilities),


 small and simple GUI programs. Why not to have dll (so) for dynamic


 and the developer can choose which stile to use? I do not think that


 hard to do, or dlls will create problems.



 "Walter" <newshound digitalmars.com> wrote in message
 news:c7521u$1dnt$2 digitaldaemon.com...
 "Elbert Lev" <elbertlev hotmail.com> wrote in message
 news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few


 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb.




 me
 why?

 I suspect, that this happens because of static linking to runtime


 But may be I'm wrong and bloated executable is just a price you have




 pay
 for great features, D offeres.  I understand that now the




 space
 is cheap, but...

In general, a D executable will be the same size as a C++ one plus



 40k
 for the garbage collector code. However, as Ilya pointed out, D code

 grow slower than C++ code.



May 04 2004
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In a system like linux (and most others) the "grep" program will be cached in
memory, so the 40K will only load once;  but if it still bothers you, put
"gc.disable()" at the top of main().  Then the GC won't run, and therefore,
won't be paged in (saving you a few milliseconds).  Dynamic paging means only
the used parts of the program are paged in, so its okay to add big libraries
that you don't use.

In this light, a shared library is actually worse - the linker has to iterate
over it and fix pointers each time it links.  In KDE C++ applications, the large
numbers of virtual pointer-heavy classes were causing this linking phase to drag
out to as much as a quarter or half of a second per process run.

So, if you use a lot of virtual pointers, static linking is your friend, even if
the app gets bigger.  Dynamic paging is cheap, linking shared objs is less so.

Kevin

In article <c786a3$2q2$1 digitaldaemon.com>, Matthew says...
I'd be more interested in a super-compact GC, possibly with an incredibly
dumb/slow implementation.

Since a great many utilities are run-briefly things, it would not pose a problem
if there was simply no GC. I'd like to be able to select a phobos-light.lib.

"Lev Elbert" <elbertlev comcast.net> wrote in message
news:c76cic$ci0$1 digitaldaemon.com...
 OK! Statically linked run-time library is fine for a big program, but there
 are cases when one needs a set of utilities (like Unix text utilities), or
 small and simple GUI programs. Why not to have dll (so) for dynamic linking
 and the developer can choose which stile to use? I do not think that this is
 hard to do, or dlls will create problems.



 "Walter" <newshound digitalmars.com> wrote in message
 news:c7521u$1dnt$2 digitaldaemon.com...
 "Elbert Lev" <elbertlev hotmail.com> wrote in message
 news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a few


 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb. explain

 why?

 I suspect, that this happens because of static linking to runtime


 But may be I'm wrong and bloated executable is just a price you have to

 for great features, D offeres.  I understand that now the memory/disk

 is cheap, but...

In general, a D executable will be the same size as a C++ one plus about

 for the garbage collector code. However, as Ilya pointed out, D code

 grow slower than C++ code.



May 04 2004
next sibling parent "Lev Elbert" <elbertlev comcast.net> writes:
//In a system like linux (and most others) the "grep" program will be cached
in
memory, so the 40K will only load once;

    Only if the system is doing nothing (like most desktop systems are
supposed to do). If you have a server, which runs tons of programs, "grep in
memory" will be trashed by the database endine (for example).

    I'm not talking about the speed or memory footprint, but disk and
distribution size. What you are saying is correct, but using shared
libraries would save 50% or more of the size of the executable. Now consider
such a system: 3 executables and 10 dll's. All written in D. Now you have
(with no run-time dll) 13 statically linked gc modules. So half meg for
nothing.


"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:c78dht$e5i$1 digitaldaemon.com...
 In a system like linux (and most others) the "grep" program will be cached

 memory, so the 40K will only load once;  but if it still bothers you, put
 "gc.disable()" at the top of main().  Then the GC won't run, and

 won't be paged in (saving you a few milliseconds).  Dynamic paging means

 the used parts of the program are paged in, so its okay to add big

 that you don't use.

 In this light, a shared library is actually worse - the linker has to

 over it and fix pointers each time it links.  In KDE C++ applications, the

 numbers of virtual pointer-heavy classes were causing this linking phase

 out to as much as a quarter or half of a second per process run.

 So, if you use a lot of virtual pointers, static linking is your friend,

 the app gets bigger.  Dynamic paging is cheap, linking shared objs is less

 Kevin

 In article <c786a3$2q2$1 digitaldaemon.com>, Matthew says...
I'd be more interested in a super-compact GC, possibly with an incredibly
dumb/slow implementation.

Since a great many utilities are run-briefly things, it would not pose a


if there was simply no GC. I'd like to be able to select a


"Lev Elbert" <elbertlev comcast.net> wrote in message
news:c76cic$ci0$1 digitaldaemon.com...
 OK! Statically linked run-time library is fine for a big program, but



 are cases when one needs a set of utilities (like Unix text utilities),



 small and simple GUI programs. Why not to have dll (so) for dynamic



 and the developer can choose which stile to use? I do not think that



 hard to do, or dlls will create problems.



 "Walter" <newshound digitalmars.com> wrote in message
 news:c7521u$1dnt$2 digitaldaemon.com...
 "Elbert Lev" <elbertlev hotmail.com> wrote in message
 news:c730ri$1di8$1 digitaldaemon.com...
 I'm a hardcore C++ programer. Last night downloaded D and read a





 pages
 about ideas behind it. And I agree  with them! Them I automatically

 supplied examples. All worked, but I was supprised by the produced
 executable sizees. A very basic console application is 60-70 kb.





 me
 why?

 I suspect, that this happens because of static linking to runtime


 But may be I'm wrong and bloated executable is just a price you





 pay
 for great features, D offeres.  I understand that now the





 space
 is cheap, but...

In general, a D executable will be the same size as a C++ one plus




 40k
 for the garbage collector code. However, as Ilya pointed out, D code

 grow slower than C++ code.




May 04 2004
prev sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Kevin Bealer wrote:
 In a system like linux (and most others) the "grep" program will be cached
 in
 memory, so the 40K will only load once;  but if it still bothers you, put
 "gc.disable()" at the top of main().  Then the GC won't run, and
 therefore,
 won't be paged in (saving you a few milliseconds).  Dynamic paging means
 only the used parts of the program are paged in, so its okay to add big
 libraries that you don't use.
 
 In this light, a shared library is actually worse - the linker has to
 iterate
 over it and fix pointers each time it links.  In KDE C++ applications, the
 large numbers of virtual pointer-heavy classes were causing this linking
 phase to drag out to as much as a quarter or half of a second per process
 run.
 
 So, if you use a lot of virtual pointers, static linking is your friend,
 even if
 the app gets bigger.  Dynamic paging is cheap, linking shared objs is less
 so.

Interesting aspect! Anyway: this should - if possible - be left as a decision to the distibutor/administrator. Even if there are good reasons for static linking of libraries, it will be seen as a limitation of the compiler/linker/language, if shared libraries are not, or not fully, supported. There certainly are situations, where executable size is more important than execution time or RAM usage.
May 04 2004
prev sibling parent reply "Lev Elbert" <elbertlev comcast.net> writes:
THIS IS MY FIRST EXPERIMENT WITH D.

Taking in the account what was written by other people, I decided to write a
simple program, which "spies" on the file. Periodically it reads the file
(from current position) and prints it on the screen. Another program writes
text to the file. Very convenient for debugging of services. The program is
attached.

It does not work(!), because File.open(name, FileMode.In) opens the text
file in such a way, that "another" program can't update it! (In "C"  FILE *f
= fopen(argv[1], "rb"); ALLOWS file updates by another process.)

The size of the executable is astonishing! 80K. So not only gc (as was
mentioned by people), but Stream and File are statically linked. I beleive,
that in "real life" program, which used most of the phobos,  whoole
phobos.lib, as well as, third party libs will be linked to the executable
(So 400K+)

Give me a break!
May 05 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Lev Elbert" <elbertlev comcast.net> wrote in message
news:c7at3s$18hr$1 digitaldaemon.com...
 THIS IS MY FIRST EXPERIMENT WITH D.

 Taking in the account what was written by other people, I decided to write

 simple program, which "spies" on the file. Periodically it reads the file
 (from current position) and prints it on the screen. Another program

 text to the file. Very convenient for debugging of services. The program

 attached.

 It does not work(!), because File.open(name, FileMode.In) opens the text
 file in such a way, that "another" program can't update it! (In "C"  FILE

 = fopen(argv[1], "rb"); ALLOWS file updates by another process.)

Try closing the file after the spying is done! or declare it like: auto File file = new File(); and this way the destructor will be called when exiting the scope.
 The size of the executable is astonishing! 80K. So not only gc (as was
 mentioned by people), but Stream and File are statically linked. I

 that in "real life" program, which used most of the phobos,  whoole
 phobos.lib, as well as, third party libs will be linked to the executable
 (So 400K+)

I don't think executable size is a problem in D, it is true that like you say a basic console application is 60-70kB, but try writing a larger program. I have a really complex and relativelly big program in D and it is only 120kB. That isn't souch a big increase in size.
 Give me a break!

May 05 2004
parent "Lev Elbert" <elbertlev comcast.net> writes:
 Try closing the file after the spying is done!
 or declare it like:
 auto File file = new File();
 and this way the destructor will be called when exiting the scope.

Will not help! The read position will not be preserved. Attached is "C" program. Try to run it against the file. Then open the file in a notepad, add a few lines and save. You will see che changes on the screen By the way, a little bit off topic, but I compiled logspy.cpp with: Borland free compiler, with MSC6 and with MinGW-gcc. All work the same way, but when I compiled it with dmc.exe - the program does not work. while (1) { while (1) { c = fgetc(f); printf("%d\n", (int)c); if (c == EOF) break; putchar(c); } Sleep(1000); } c = fgetc(f) always returns -1 (EOF). Attached are both programs C and D "Ivan Senji" <ivan.senji public.srce.hr> wrote in message news:c7avej$1c8q$1 digitaldaemon.com...
 "Lev Elbert" <elbertlev comcast.net> wrote in message
 news:c7at3s$18hr$1 digitaldaemon.com...
 THIS IS MY FIRST EXPERIMENT WITH D.

 Taking in the account what was written by other people, I decided to


 a
 simple program, which "spies" on the file. Periodically it reads the


 (from current position) and prints it on the screen. Another program

 text to the file. Very convenient for debugging of services. The program

 attached.

 It does not work(!), because File.open(name, FileMode.In) opens the text
 file in such a way, that "another" program can't update it! (In "C"


 *f
 = fopen(argv[1], "rb"); ALLOWS file updates by another process.)

Try closing the file after the spying is done! or declare it like: auto File file = new File(); and this way the destructor will be called when exiting the scope.
 The size of the executable is astonishing! 80K. So not only gc (as was
 mentioned by people), but Stream and File are statically linked. I

 that in "real life" program, which used most of the phobos,  whoole
 phobos.lib, as well as, third party libs will be linked to the


 (So 400K+)

I don't think executable size is a problem in D, it is true that like you say a basic console application is 60-70kB, but try writing a larger program. I have a really complex and relativelly big program in D and it is only 120kB. That isn't souch a big increase in size.
 Give me a break!


May 05 2004