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
phk at phk.freebsd.dk
Tue Jul 22 17:04:01 PDT 2003
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...
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
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.
More information about the cvs-all