In some instances, there could be a hit for not inlining.  There are two
reasons for this, at least one of which has already been given:

1) high function call overhead for some platforms
2) for functions that are surrounded by code which doesn't get called
often, you may have to flush a page from cache to bring in the code for
said function.  inlining keeps the cache warm for the calling code

The drawbacks to inlining:

1) larger text size
2) possible cache-related impact due to code being larger

For macros (instead of inlining), there is one more potential impact:

3) less optimization due to lack of scoping (register scheduling)

Hope that helps.

    -- Garrett

Simon Burge wrote:

>Izumi Tsutsui wrote:
>
>  
>
>>Some discussion is going on tech-kern, but is it OK
>>to commit the attached diff against mips/pmap.c?
>>    
>>
>
>Not inlining these functions results is about 2kB of kernel text saved:
>
>2680 -rwxr-xr-x  1 simonb  wheel  2728338 Nov 23 10:42 netbsd.OLD*
>2680 -rwxr-xr-x  1 simonb  wheel  2728338 Nov 23 10:46 netbsd.inline*
>2672 -rwxr-xr-x  1 simonb  wheel  2726290 Nov 23 10:47 netbsd.no-inline*
>
>pa_to_pvh() compiles to 184 bytes and pa_to_attribute() compiles to 188
>bytes, and there's a few calls to each.
>
>I'm curious to know if there's much of a performance hit at all for not
>inlining?
>
>Simon.
>--
>Simon Burge                            <simonb@wasabisystems.com>
>NetBSD Support and Service:         http://www.wasabisystems.com/
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134