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 <Pine.BSF.4.21.0307221647490.51429-100000 at InterJet.elischer.org>, Ju
lian Elischer writes:
>
>
>On Wed, 23 Jul 2003, Poul-Henning Kamp wrote:
>
>> 
>> You can see some of my raw data here: http://phk/misc/inline.txt
>>
>
>This doesn't resolve...

sorry,
	http://phk.freebsd.dk/misc/inline.txt

And while I'm here, let me show you guys the most compelling argument
why we should be critical of even trivial uses of __inline.

(My apologies to Justin for using his code as an example, it is not
meant as a critisism of Justin or his code, I belive we all could
have fallen in this trap)

If you look in aic79xx_inline.h you will find a family of functions
called ahd_in[bwlq]_scbram().

The base text size we have with the inlining is:
	 100718    4496       0  105214   19afe aic79xx.o

then a bug is fixed in ahd_inb_scbram() and due to the cascading
effect of the inlines we suddendly find that we have 4976 bytes
more code to execute:

	 105694    4496       0  110190   1ae6e aic79xx.o


If on the other hand the bottom function in the cascade, ahd_ibb_scbram()
was not inlined in the first place, we would have had before the bugfix:

	  98878    4496       0  103374   193ce aic79xx.o

and and after:

	  98926    4496       0  103422   193fe aic79xx.o


How many of you are actually in the habit of reevaluating if
a "harmless bugfix" has any implications in relation to inlining ?

That is the sort of thing which makes me belive that unless proven
beneficial (by one of the two criteria), inline is harmful.

-- 
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.