From owner-freebsd-hackers  Sat Jul 13 21:49:52 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA07616
          for hackers-outgoing; Sat, 13 Jul 1996 21:49:52 -0700 (PDT)
Received: from walkabout.asstdc.com.au (root@walkabout.asstdc.com.au [202.12.127.73])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA07608
          for <hackers@freebsd.org>; Sat, 13 Jul 1996 21:49:47 -0700 (PDT)
Received: (from imb@localhost)
          by walkabout.asstdc.com.au (8.7.5/BSD4.4) id OAA00418
          Sun, 14 Jul 1996 14:49:39 +1000 (EST)
From: michael butler <imb@asstdc.com.au>
Message-Id: <199607140449.OAA00418@walkabout.asstdc.com.au>
Subject: Re: Kernel Config (Was: GENERIC Kernel Debate)
To: hasty@rah.star-gate.com (Amancio Hasty)
Date: Sun, 14 Jul 1996 14:49:39 +1000 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199607140320.UAA00618@rah.star-gate.com> from Amancio Hasty at "Jul 13, 96 08:20:51 pm"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> The issue of 30minutes for a kernel compile has got to be due
> to gcc . Not sure what changed between gcc-1.42 and and gcc-2.x however
> simple minded experiments have shown that gcc-2.x takes about 3 times
> longer to compile. 

I feel that one-time compilation overheads are the last on the list of
priorities when you want a kernel that performs reasonably well. If you want
faster compilation, simply remove the "-O". You can have it one way or the
other; both is not (currently) an option.

> The other major factor is the cpu/disk/controller and
> if you have a minimally configured system, memory is important.

On a machine with enough memory, you can add "-pipe" to both CFLAGS-like
options in /etc/make.conf. In fact, I use "-m486 -O2 -pipe" on all my
"production" kernels and binaries (noting, for the less up-to-date, that
2.1-R also requires "-fno-strength-reduce" for "correct" code generation).

Having transitioned my own networks from Interactive SVR3.2, it should be
noted that the reason why SysV-derived systems allow "quick" compilation of
new user configurations is that (almost) the only things they translate are
the "space.c" files containing tables (plain data) referencing the object
code stored in one or more system libraries (since you don't get the
source-code). The compiler used doesn't for this have to be fancy .. no
amount of optimisation is likely to have any impact on a data-only
structure. Greater flexibility and performance has its price .. IMHO it's
well worth the one-time overhead,

	michael