Date: Tue, 22 Jul 2003 17:32:12 -0700 From: Peter Wemm <peter@wemm.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: Julian Elischer <julian@elischer.org> Subject: Re: 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 Message-ID: <20030723003212.1606C2A8B2@canning.wemm.org> In-Reply-To: <16831.1058918630@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
"Poul-Henning Kamp" wrote: > That is the sort of thing which makes me belive that unless proven > beneficial (by one of the two criteria), inline is harmful. There is a great leap there. Just because somebody isn't willing to spend considerable time to re-prove that the runtime improvement is still there to your satisfaction, that doesn't mean that it is harmful. Take the i386 interrupt vector code. Thats an example where it is massively inlined. Having a non-inlined function that does all the calculations and bit shifting is much smaller in code size, but slower at runtime. You have not proven your assertion that smaller code is implicitly faster. It might be more convenient for you to measure, but it doesn't mean anything without the same exhaustive runtime measurement that you would have us do. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030723003212.1606C2A8B2>