cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c

[Marcel Moolenaar]

On Wed, Jul 23, 2003 at 01:18:07AM +0200, Poul-Henning Kamp wrote:
> In message <20030722230731.GB61493 at athlon.pn.xcllnt.net>, Marcel Moolenaar writ
> es:
> >On Wed, Jul 23, 2003 at 12:56:34AM +0200, Poul-Henning Kamp wrote:
> >> 
> >> And the only two criteria I think are trivial to use for proving an
> >> actual benefit is:
> >> 	1. less code is generated.
> >> 	2. it runs faster in tests.
> >
> >criterium 1 is the worst possible. Only criterium 2 makes sense.
> 
> No, if inlining a functions results in less code overall it also,
> ipso facto results in faster execution.

Proof it. I can give a counter example to show that I seriously
doubt this statement:

Inlining a function that has only 1 caller, and the call is on
a cold path (ie a nested if or else that's almost never executed)
can create an interference with the hot path by virtue of increasing
branch distances (over the inlined code -- cache interference) or
due to code commoning or code motion or simply because the compiler
picks the wrong heuristic for edge weights, because the almost never
executed code is larger and is chosen as the more important of the
if-then-else cases. The non-inlined code is likely to be larger due
to the call-site and function prologue and epilogue, but can easily
yield better performance do it being out of the way of the common
path.

Inlining cold code hardly ever benefits, no matter how much it
decreases the overall code size. It all boils down to locality:
the prime characteristic that makes caches work.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net