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

[Poul-Henning Kamp]

In message <20030723073554.GA11876 at HAL9000.homeunix.com>, David Schultz writes:

>I agree with your algorithm, as long as you're not going to beat
>people over the head with it for every inline function until they
>submit benchmarks.

I have better ways to use my time.

>Your cavalier attitude towards all this bothers me.  You presume
>the right to make gratuitous changes to other people's code unless
>they prove to your satisfaction that they were right in the first
>place.  If you're going to go around and remove some inlines,
>that's great; many of them are probably inappropriate.  But be
>prepared to justify the changes if someone---particularly the
>maintainer---objects.  ``It makes the object code bigger'' is not
>justification in itself.

I have not removed any inlines without checking if they had a
measurable effect.  Also my criteria was "It makes the object code
_much_ bigger".  Once adding an inline starts to soak up half a
page, it needs to show positive effect.

Again, my objective was to make it possible to set the GCC inlining
so low that it would in fact warn about unintended inline explosion
such as the ahd_in[bwlq]_scbram() case.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.