Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: Speed costs (Re: MWC's Coherent - A Lemon...)
Message-ID: <136625@sun.Eng.Sun.COM>
Date: 4 Jun 90 21:51:33 GMT
References: <3886@darkstar.ucsc.edu> <136369@sun.Eng.Sun.COM> <27415@eerie.acsu.Buffalo.EDU> <4042@darkstar.ucsc.edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Followup-To: /dev/null
Organization: Sun Microsystems, Mountain View
Lines: 38

In article <4042@darkstar.ucsc.edu> keller@saturn.ucsc.edu (Jeffrey M. Keller) writes:
>Well, i wasn't going to comment either, but... ;-)
>As i pointed out to McVoy in email, the binary size seems to be inflated
>by the dynamic linking: in X11R3 on a Sun-3 under SunOS 3.5 (no shared
>libraries), the xclock binary is 376K.  Granted, that's still huge, but
>it suggests to me that the 1.3M (and even the 844K) figure is misleading.
>Since i approve of shared libraries, i would like to think that the effective
>cost of the 1.3M (or whatever) dynamically linked xclock is <= that of the
>376K statically linked one.
>--
>Jeff Keller           keller@saturn.ucsc.edu           (408)425-5416

Let me try one last time.  After this I give up.

The xclock number that I have is from an old version on a Dec 3100 running
X11R3 (I think).  And it was around 1.3meg (around means that it might have
been a 50 or a 100K bigger or smaller).  Furthermore, an xclock running a
sparc station 1, running SunOS 4.1, X11 R4 FCS (no patches), uses about a
meg of translations.  That means that that process is actively using at
least 1 meg of virtual address space and that that portion of its address
space is backed by real incore pages.

Many of those pages have the potential to be shared.  That does not mean
that they are shared.  That does not reduce or increase the effective size
of the binary (well, maybe there's a page of dynamic linking junk, but
that's noise).

You still have to bring all of those pages in from disk.  You have to have
all of those (unshared) translations loaded up.  You have to run the pager
over all of those pages.  They don't go away.  More processes may be using
them but they are really there.  In memory.  Using up time and space.

Just as a sanity check, compare to the first version of the Mac.  That had
the OS (what there was of it - basically a file system) and the window
system in a 128K ROM.  Your average X server is about a meg or more.  On the
*same* architecture.
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com