Shared libraries are not necessary

terryl at sail.LABS.TEK.COM terryl at sail.LABS.TEK.COM
Fri Jun 7 08:42:11 AEST 1991


In article <300 at titccy.cc.titech.ac.jp> mohta at necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>In article <9640 at sail.LABS.TEK.COM> terryl at sail.LABS.TEK.COM writes:
>
>>     Here's a suggestion (NOT a request): Do a little survey of a company, and
>>find out how many workstations are running some sort of windowing system (be it
>>X, News, <whatever>).
>
>>     I have been technical, and who said anything about ldd & size??? I happen
>
>You are quite commercial (in itself, not bad), not technical at all.

     Beautiful ad homiem attack. Stick to the facts.

>>What I was responding to was your claim that "only one X
>>application runs at a time",
>
>That is not my claim at all.

     Oh, yes it was. It wasn't your only claim, just one of many. To wit, see
article with Message-ID of 264 at titccy.cc.titech.ac.jp; you start the article
thusly:

	Now, perhaps, it is time to show that shared libraries often increase
	memory consumption.

	If, as if often the case, we are running only one X applications, you
	lose.

     Other people have already responded to your other claims, so I chose
not to.

>>     No, you haven't proven this one yet. The ONLY thing that has been proven
>>is that executables linked with shared libraries use more VIRTUAL memory than
>>statically linked executables, due to the fact that ALL of the text space of
>>a shared library gets loaded.
>
>As text (including text of shared libraries) can be demand paged from
>executable files, you don't have to provide any swap space for text

     And what does that have to do with the price of pickles in Denmark?? Your
response has absolutely nothing to do with my remarks above. As you are so
fond of saying, be technical.

>>I haven't seen any facts to support the leap
>>to PHYSICAL memory, yet.
>
>You had better be technical and accept the result of the measurement.


     What measurements?? I haven't seen any yet. The only measurements I've
seen that I'll accept as fact is the fact I stated above (about using more
VIRTUAL memory...). My suggestion is that YOU be technical and provide the
measurements. As a start, I'll provide some additional measurements on my
system (without shared libraries):

 F S   UID   PID  PPID  C PRI NI   ADDR   SZ:RSS    WCHAN TTY      TIME COMD
10 S 17185  1040     1  0  26 24 13c528  246:183   1b9d88 ?        0:09 xterm
10 S 17185   256   211  0  26 24 13b9fc  171:59    1b9d88 ?        0:25 xeyes
10 S 17185   255   211  0  26 24 13b8f8  176:76    1b9d88 ?       201:38 xclock
10 S 17185   253   211  0  26 24 13b6f0  245:114   1b9d88 ?        0:00 xterm
10 S 17185   214   211  0  26 24 13b4e8  326:265   1b9d88 ?        0:12 mwm
10 S 17185   211   201  0  26 20 13b3e4  245:122   1b9d88 ?        0:01 xterm
10 S     0   191   185  0  26 20 13afd4  245:124   1b9d88 ttyp1    0:01 xterm
10 S     0   185   181  0  30 20 139e90  224:93    139e70 ttyp0    0:01 xdm
10 S     0   184   181  0  26 20 13997c 2037:564   1b9d88 ?        3:38 X

     What's interesting here is the SZ:RSS column. SZ is the VIRTUAL memory
size of the process, and RSS is the Resident Set Size (i.e. the amount of
PHYSICAL memory it is currently occupying). Sizes are in terms of 4k pages.

     For example, the X server (listed as X in the above listing), consumes a
little under 8 Mbytes of VIRTUAL memory, but is using only a little over 2
Mbytes of PHYSICAL memory, a little more than 25 % of its VIRTUAL size.
Unfortunately, there is no ready (or easy way) to tell how much of the PHYSICAL
memory is text vs. data.

     This will be my last post on this. When people have to resort to lying to
prove their point, it's not worth my time or effort to respond to it.

__________________________________________________________
Terry Laskodi		"There's a permanent crease
     of			 in your right and wrong."
Tektronix		Sly and the Family Stone, "Stand!"
__________________________________________________________



More information about the Comp.unix.internals mailing list