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.
>> >
>> >
>>
>>
>
>

//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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>

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.

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!

"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
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.)

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
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+)

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!
>
>
>
>

> 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
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.)
>
> 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
> 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+)
>
> 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!
> >
> >
> >
> >
>
>

"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
avoid
> the GC code.

Sure. Write your own stub functions in std.gc to prevent the library ones from being linked in.

"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.