Subject: Re: proposal: libcc1 -> static
To: None <tech-toolchain@netbsd.org>
From: Ian Dall <Ian.Dall@dsto.defence.gov.au>
List: tech-toolchain
Date: 01/05/1999 17:15:32
Todd Vierling <tv@pobox.com> writes:

  > On Sun, 3 Jan 1999, David Brownlee wrote:
  > : 	Wasn't one of the ideas behind going to libcc1.so to share memory
  > : 	between different passes of the compiler to make using pipes
  > : 	feasible. (The whole point being to speed up compiling).

  > Demand paged VM == for the same language, you get this benefit anyway.

He is talking different phases, not different instances of the same
compiler.

  > Remember that binaries' text pages are shared, even between different
  > invocations, as well as unmodified data pages.  A shared object actually
  > slows down each invocation because of all the reloc fixups.  Christoph
  > drilled this reminder into me.  :>

  > It's only when you heavily mix languages that you get a speedup with the
  > shared object, and then, it's not much of a speedup.

With static linking there will be no sharing of pages between cc1, as
and ld which you might want if you are using the -pipe option.

However, I don't really think -pipe is very good anyway and instead
avoid disk traffic by making TMPDIR a memory file system.

  > : 	The disk space savings have to be pretty small - we currently link
  > : 	four binaries {cc1,cc1obj,cc1plus,f771} against libcc1 (which is
  > : 	around 1.4MB on an i386 system). I don't know how much of the
  > : 	library is used by each binary.

It isn't just *disk* space. Depending on your job mix it can also save
RAM. It can I believe also make the RAM situation worse (more pages
touched) so there is no simple best solution.

Ian