From owner-cvs-all@FreeBSD.ORG Tue Jul 22 16:49:13 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 8A9E637B401; Tue, 22 Jul 2003 16:49:13 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7277643F3F; Tue, 22 Jul 2003 16:49:12 -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 h6MNn8V3031415; Tue, 22 Jul 2003 23:49:08 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 h6MNn75H016722; Wed, 23 Jul 2003 01:49:07 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Jul 2003 16:39:23 PDT." <20030722233923.GD61493@athlon.pn.xcllnt.net> Date: Wed, 23 Jul 2003 01:49:06 +0200 Message-ID: <16721.1058917746@critter.freebsd.dk> cc: "Alan L. Cox" cc: src-committers@FreeBSD.org cc: Bosko Milekic cc: Bruce Evans cc: cvs-src@FreeBSD.org cc: Steve Kargl 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: Tue, 22 Jul 2003 23:49:13 -0000 In message <20030722233923.GD61493@athlon.pn.xcllnt.net>, Marcel Moolenaar writ es: >On Wed, Jul 23, 2003 at 01:18:07AM +0200, Poul-Henning Kamp wrote: >> In message <20030722230731.GB61493@athlon.pn.xcllnt.net>, Marcel Moolenaar writ >> es: >> >On Wed, Jul 23, 2003 at 12:56:34AM +0200, Poul-Henning Kamp wrote: >> >> >> >> And the only two criteria I think are trivial to use for proving an >> >> actual benefit is: >> >> 1. less code is generated. >> >> 2. it runs faster in tests. >> > >> >criterium 1 is the worst possible. Only criterium 2 makes sense. >> >> No, if inlining a functions results in less code overall it also, >> ipso facto results in faster execution. > >Proof it. I can give a counter example to show that I seriously >doubt this statement: > >Inlining a function that has only 1 caller, and the call is on >a cold path (ie a nested if or else that's almost never executed) Why on earth would you even think about inlining in that case ? We are not talking about heuristics for getting the compiler to mindlessly inline functions here. We are talking about the burden of proof the programmer must lift, once he has spotted what he thinks is a promising inline candidate. -- 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.