Date: Wed, 23 Jul 2003 09:57:22 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: David Schultz <das@FreeBSD.ORG> Cc: cvs-all@FreeBSD.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: <20886.1058947042@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 23 Jul 2003 00:35:54 PDT." <20030723073554.GA11876@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030723073554.GA11876@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20886.1058947042>