From owner-freebsd-hackers  Sun Jul 14 18:38:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA00646
          for hackers-outgoing; Sun, 14 Jul 1996 18:38:58 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA00630;
          Sun, 14 Jul 1996 18:38:53 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id UAA10916; Sun, 14 Jul 1996 20:38:26 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199607150138.UAA10916@dyson.iquest.net>
Subject: Re: Preach it (was Some recent changes to GENERIC)
To: bde@zeta.org.au (Bruce Evans)
Date: Sun, 14 Jul 1996 20:38:26 -0500 (EST)
Cc: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG,
        joerg_wunsch@uriah.heep.sax.de, jonny@gaia.coppe.ufrj.br,
        pjchilds@imforei.apana.org.au, sos@FreeBSD.ORG
In-Reply-To: <199607150044.KAA12373@godzilla.zeta.org.au> from "Bruce Evans" at Jul 15, 96 10:44:46 am
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-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> A simple guidline: don't inline anything that makes a function call,
> perhaps even to an inline function.  pmap.c more or less follows this
> rule except it calls nested inline functions a lot.  Most of the 3K
> seems to be caused by nesting.  Perhaps more functions should be
> split up like pmap_allocpte() (to have a small usual case and call
> a non-inline function for special cases).
> 
That is the approach that I have been trying to take, but unfortunately,
the pmap_allocpte case is not valid anymore for that, because I am
expunging the PHYS_TO_VM_PAGE evility :-), which includes sometimes
vm_page_lookup for the replacement.

How's about this (of course, exceptions are the rule :-)):
	(Someone with better language skills might need to clarify it)

	In general, it is not a good idea to inline functions
	that call other inline functions.  Also, it is generally
	a good idea to inline only small functions.  Most of the
	time, inlining functions that call other (inline/non-inline)
	functions is not very profitable.

	One case where using inlines for large OR small functions can
	be advantageous is when compile time evaluation will improve
	code generation by excluding unneeded conditional expressions
	in the code.

John