Date: Sat, 21 Sep 1996 17:39:55 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: roderick@gate.net (Roderick Schertler) Cc: questions@freebsd.org Subject: Re: Shells shells shells? Message-ID: <199609212239.RAA01564@dyson.iquest.net> In-Reply-To: <pziv97czyt.fsf@eeyore.ibcinc.com> from "Roderick Schertler" at Sep 21, 96 05:36:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Fri, 20 Sep 1996 09:03:20 -0500 (EST), "John S. Dyson" <toor@dyson.iquest.net> said: > > > > Shared libs both do not save memory in the case of progs like bash, > > but also slow down fork/exec times significantly. > > Would someone elaborate on this sentence, particularly the first half? > Shared libs don't have a very good locality of ref relative to the process that they are linked to. For example, the associated .data and .bss are not intimately linked with the application, but with the rest of the shared lib. The shared libs contain lots of excess routines, and when you fault pages in, you are many times getting data and text that you simply do not need. When a COW fault occurs on a shared lib .data page, you are likely only going to need a small part of that page. For some interesting info, look at the /proc/XXX/map file in -current. Since your shell runs with many concurrent invocations, your .text will be fully shared amongst the various shells, and the .data and .bss memory footprints will be smaller than if they were linked with shared libs. IMO, shared libs are mostly useful for a couple of reasons... Processes that run with few concurrent instances, disk space savings, and very large libraries where the advantage is significant (like X-windows libs.) IMO, Shells are not the best choice of programs to link with shared libs... X windows programs are on the other hand, very good choices of programs to link with shared libs. Other programs are somewhere in between. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609212239.RAA01564>