digitalmars.D - Executable size
- Elbert Lev (9/9) May 02 2004 I'm a hardcore C++ programer. Last night downloaded D and read a few pag...
- imr1984 (4/13) May 02 2004 Id say that yes, its just because all D programs have to linked statical...
- Andrew Edwards (12/21) May 02 2004 compiled
- Ilya Minkov (21/30) May 02 2004 Because a very basic C++ application compiled with DigitalMars compiler
- Walter (9/18) May 02 2004 compiled
- Bruno A. Costa (6/29) May 03 2004 There is some way to completely disable GC, avoiding this extra code?
- Walter (5/8) May 15 2004 avoid
- Norbert Nemec (3/26) May 03 2004 Is there a fundamental reason why the garbage collector code has to be
- Walter (4/6) May 15 2004 No. I just happen to dislike runtime-library-as-dll because of the DLL h...
- Lev Elbert (11/30) May 03 2004 OK! Statically linked run-time library is fine for a big program, but th...
- Matthew (6/40) May 04 2004 I'd be more interested in a super-compact GC, possibly with an incredibl...
- Lev Elbert (19/66) May 04 2004 phobos-light.lib.
- Kevin Bealer (14/59) May 04 2004 In a system like linux (and most others) the "grep" program will be cach...
- Lev Elbert (34/98) May 04 2004 //In a system like linux (and most others) the "grep" program will be ca...
- Norbert Nemec (8/28) May 04 2004 Interesting aspect! Anyway: this should - if possible - be left as a
- Lev Elbert (38/38) May 05 2004 THIS IS MY FIRST EXPERIMENT WITH D.
- Ivan Senji (16/31) May 05 2004 a
- Lev Elbert (69/110) May 05 2004 Will not help! The read position will not be preserved. Attached is "C"
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
imr1984 <imr1984_member pathlink.com> 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
"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 automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb. explainmewhy?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 topayfor great features, D offeres. I understand that now the memory/diskspaceis cheap, but...
May 02 2004
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
"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 automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb. explainmewhy? 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 topayfor great features, D offeres. I understand that now the memory/diskspaceis 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
Walter wrote:"Elbert Lev" <elbertlev hotmail.com> wrote in message news:c730ri$1di8$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 avoid the GC code. Thanks, Bruno.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 automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb. explainmewhy? 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 topayfor great features, D offeres. I understand that now the memory/diskspaceis 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 03 2004
"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 itavoidthe GC code.Sure. Write your own stub functions in std.gc to prevent the library ones from being linked in.
May 15 2004
Walter wrote:"Elbert Lev" <elbertlev hotmail.com> wrote in message news:c730ri$1di8$1 digitaldaemon.com...Is there a fundamental reason why the garbage collector code has to be statically linked?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 automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb. explainmewhy? 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 topayfor great features, D offeres. I understand that now the memory/diskspaceis 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 03 2004
"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
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...pagesI'm a hardcore C++ programer. Last night downloaded D and read a fewlibrary.about ideas behind it. And I agree with them! Them I automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb. explainmewhy? I suspect, that this happens because of static linking to runtime40kBut may be I'm wrong and bloated executable is just a price you have topayfor great features, D offeres. I understand that now the memory/diskspaceis cheap, but...In general, a D executable will be the same size as a C++ one plus aboutfor the garbage collector code. However, as Ilya pointed out, D codeshouldgrow slower than C++ code.
May 03 2004
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...pagesI'm a hardcore C++ programer. Last night downloaded D and read a fewlibrary.about ideas behind it. And I agree with them! Them I automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb. explainmewhy? I suspect, that this happens because of static linking to runtime40kBut may be I'm wrong and bloated executable is just a price you have topayfor great features, D offeres. I understand that now the memory/diskspaceis cheap, but...In general, a D executable will be the same size as a C++ one plus aboutfor the garbage collector code. However, as Ilya pointed out, D codeshouldgrow slower than C++ code.
May 04 2004
Since a great many utilities are run-briefly things, it would not pose aproblemif there was simply no GC. I'd like to be able to select aphobos-light.lib. 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 aproblemif there was simply no GC. I'd like to be able to select aphobos-light.lib."Lev Elbert" <elbertlev comcast.net> wrote in message news:c76cic$ci0$1 digitaldaemon.com...thereOK! Statically linked run-time library is fine for a big program, butorare cases when one needs a set of utilities (like Unix text utilities),linkingsmall and simple GUI programs. Why not to have dll (so) for dynamicthis isand the developer can choose which stile to use? I do not think thatexplainhard 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...pagesI'm a hardcore C++ programer. Last night downloaded D and read a fewabout ideas behind it. And I agree with them! Them I automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb.tomelibrary.why? I suspect, that this happens because of static linking to runtimeBut may be I'm wrong and bloated executable is just a price you havememory/diskpayfor great features, D offeres. I understand that now theaboutspaceis cheap, but...In general, a D executable will be the same size as a C++ one plus40kfor the garbage collector code. However, as Ilya pointed out, D codeshouldgrow slower than C++ code.
May 04 2004
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...pagesI'm a hardcore C++ programer. Last night downloaded D and read a fewlibrary.about ideas behind it. And I agree with them! Them I automaticallycompiledsupplied examples. All worked, but I was supprised by the produced executable sizees. A very basic console application is 60-70 kb. explainmewhy? I suspect, that this happens because of static linking to runtime40kBut may be I'm wrong and bloated executable is just a price you have topayfor great features, D offeres. I understand that now the memory/diskspaceis cheap, but...In general, a D executable will be the same size as a C++ one plus aboutfor the garbage collector code. However, as Ilya pointed out, D codeshouldgrow slower than C++ code.
May 04 2004
//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
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
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...
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 04 2004
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
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!
begin 666 LogSpy.d
M:6UP;W)T('-T9"YC+G=I;F1O=W,N=VEN9&]W<SL "2\O4VQE97 -"FEM<&]R
M="!S=&0N8RYS=&1I;SL)"0D)+R]P<FEN=&8-"FEM<&]R="!S=&0N<W1R96%M
M=')Y( T*"0D)>PT*"0D)8VAA<B!C(#T :49I;&4N9V5T8R I.PT*"0D)"6EF
M3W!E;D5R<F]R*0T*"0D)>PT*"0D)"6EF(" A0V]U;&1.;W1/<&5N4F5P;W)T
`
end
May 05 2004
"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 writeasimple program, which "spies" on the file. Periodically it reads the file (from current position) and prints it on the screen. Another programwritestext to the file. Very convenient for debugging of services. The programisattached. 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.)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. Ibeleive,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
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...writeTHIS IS MY FIRST EXPERIMENT WITH D. Taking in the account what was written by other people, I decided toafilesimple program, which "spies" on the file. Periodically it reads theFILE(from current position) and prints it on the screen. Another programwritestext to the file. Very convenient for debugging of services. The programisattached. 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"*fexecutable= 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. Ibeleive,that in "real life" program, which used most of the phobos, whoole phobos.lib, as well as, third party libs will be linked to thebegin 666 LogSpy1.d M:6UP;W)T('-T9"YC+G=I;F1O=W,N=VEN9&]W<SL "2\O4VQE97 -"FEM<&]R M;E)E<&]R=&5D(#T M;BAA<F=S6S%=+" B<F(B*3L-" D)"6EF(" A9BD-" D)"7L-" D)"0EI9B H M" D)"7T-" D)"65L<V4-" D)"7L-" D)"6EN="!C.PT*"0D)"6EF(" A0V]U M971C*&8I.PT*"0D)"0D)<')I;G1F*"(E9%QN(BP *&EN="EC*3L-" D)"0D) M"6EF("AC(#T]($5/1BD-" D)"0D)"0EB<F5A:SL-" D)"0D)"7!U=&-H87(H ` end begin 666 LogSpy.cpp M;V]L($-O=6QD;G1/<&5N4F5P;W)T960 /2!F86QS93L-"FEN="!M86EN*&EN M" D)<')I;G1F*")5<V%G92!,;V=3<'D 1FEL94YA;65<;B(I.PT*"0EG971C M24Q%("IF(#T M("AC(#T]($5/1BD-" D)"0D)"0EB<F5A:SL-" D)"0D)?0T*"0D)"7T-" D) M"0D)"0EC(#T ""GT` ` end(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