From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <89d1e7b805082123132f02e467@mail.gmail.com> Date: Mon, 22 Aug 2005 08:13:55 +0200 From: "Anselm R. Garbe" To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] 9base ports to unix In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <89d1e7b8050819053245099105@mail.gmail.com> Topicbox-Message-UUID: 7a7147e4-ead0-11e9-9d60-3106f5b1d025 On 8/21/05, Russ Cox wrote: > > I did so, because for writing rc scripts, which is my favorite > > scripting language already, it sucked to be dependent on dynamically > > linked bloat binaries from GNU. I measured that a simple sleep call to > > the default sleep program of Debian consumes about 2MB memory. Since > > sleep might be rarely used, the problem of GNU test still occurs, >=20 > I suspect you are confusing VM footprint with memory footprint. > In the case of /bin/sleep, presumably all the shared libraries > were already in memory and being used by (shared with, if you wil) > other programs. Yea I know that the execution segments of shared objects are shared among processes. Anyway, a statically linked sleep uses around 640K VM (25% of the shared one) in the case of Debian and starts up without the noticable (50 times) overhead of building the depndency tree for shared objects (even if it might be cached in some way). I see no point for dynamic linkage in small programs (well, with firefox, KDE or Gnome insanity there is no other way, if one determines 20 or 30 dependent shared libs of a single binary and if one has to expect that all data segments are leaked memory, then at least the exec segments can be shared to hide amok memory usage to the user...;). Regards, --=20 Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361