Date: Sun, 14 Jul 1996 20:38:26 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: bde@zeta.org.au (Bruce Evans) 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 Subject: Re: Preach it (was Some recent changes to GENERIC) Message-ID: <199607150138.UAA10916@dyson.iquest.net> In-Reply-To: <199607150044.KAA12373@godzilla.zeta.org.au> from "Bruce Evans" at Jul 15, 96 10:44:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607150138.UAA10916>