From owner-freebsd-current  Thu Nov 28 13:05:06 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA13176
          for current-outgoing; Thu, 28 Nov 1996 13:05:06 -0800 (PST)
Received: from dyson.iquest.net ([198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA13167
          for <freebsd-current@FreeBSD.org>; Thu, 28 Nov 1996 13:05:02 -0800 (PST)
Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id QAA03782; Thu, 28 Nov 1996 16:03:16 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199611282103.QAA03782@dyson.iquest.net>
Subject: Re: inlining (Was: users of "ft" tapes...)
To: joerg_wunsch@uriah.heep.sax.de
Date: Thu, 28 Nov 1996 16:03:16 -0500 (EST)
Cc: freebsd-current@FreeBSD.org
In-Reply-To: <199611282005.VAA16339@uriah.heep.sax.de> from "J Wunsch" at Nov 28, 96 09:05:02 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> As Poul-Henning Kamp wrote:
> 
> > >I have been thinking about un-inlining spls.  This saves 29K out of
> > >1096K text.  It may even save some time
> 
> > I generally use the rule of thumb that unless the text-size is
> > smaller as a result, then inlining is wrong.
> 
> This is hard to achieve.  I think inlining is first aimed at
> optimizing for speed, not for size.
> 
Sometimes speed == size.  Esp, on Intel architectures with small
caches.  I would like to know if there is going to be an impact on
VM perf (which is much of what people see as perf on a machine, running
various programs, and one reason why NT is so dog slow), before un-inlining
the spl's.  If it is neutral (and that is very likely), I would be
for de-inlining also.

Note that we actually had a net microbenchmark slowdown with some of my
recent VM changes, but that had to be weighed against a speedup on
large systems (by 2x-3x.)  Most of the slowdown is probably due to the
larger data structures (and larger cache footprint.)  Alas, I am just
not able to figure out how to make some of those damned things smaller,
but if anyone does have any ideas, PLEASE PLEASE let me know.

John