From owner-cvs-all@FreeBSD.ORG Wed Jul 23 00:57:25 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 852F537B401; Wed, 23 Jul 2003 00:57:25 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7651143F75; Wed, 23 Jul 2003 00:57:24 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6N7vNV3038922; Wed, 23 Jul 2003 07:57:23 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6N7vN5H020887; Wed, 23 Jul 2003 09:57:23 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: David Schultz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 23 Jul 2003 00:35:54 PDT." <20030723073554.GA11876@HAL9000.homeunix.com> Date: Wed, 23 Jul 2003 09:57:22 +0200 Message-ID: <20886.1058947042@critter.freebsd.dk> cc: src-committers@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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 07:57:25 -0000 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.