From owner-freebsd-hackers Mon Dec 18 10:40:51 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 18 10:40:47 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9548737B400 for ; Mon, 18 Dec 2000 10:40:45 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eBIIehs08404; Mon, 18 Dec 2000 11:40:44 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA92561; Mon, 18 Dec 2000 11:40:43 -0700 (MST) Message-Id: <200012181840.LAA92561@harmony.village.org> To: "Jacques A. Vidrine" Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 18 Dec 2000 12:31:08 CST." <20001218123108.A65143@hamlet.nectar.com> References: <20001218123108.A65143@hamlet.nectar.com> <20001217170316.A63227@hamlet.nectar.com> <200012172110.eBHLAfU46563@freefall.freebsd.org> <20001217151509.A63051@hamlet.nectar.com> <20001217151735.D54486@holly.calldei.com> <20001217153129.B63080@hamlet.nectar.com> <20001217153656.F54486@holly.calldei.com> <20001217155648.C63080@hamlet.nectar.com> <20001217160442.H54486@holly.calldei.com> <20001217170316.A63227@hamlet.nectar.com> <200012180501.WAA87838@harmony.village.org> Date: Mon, 18 Dec 2000 11:40:43 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001218123108.A65143@hamlet.nectar.com> "Jacques A. Vidrine" writes: : None taken. It is however a simple and safe optimization, with no : apparent downsides. It has the same attraction as using bit shifts : instead of multiplication/division, or saving the value from a function : call that will be needed again later, even if you know the function call : is trivial. You are trading a test against zero and code obfuscation against a function call. The function call is typically much less than even a multiplication or division would be. You get clearer, easier to read code that is smaller by allowing free to do its job and not trying to optimize things. : > I doubt that you could measure any difference between : > if (foo) free(foo); : > and free(foo); : > : > in the real world. : : This is probably correct for most applications. : : Nevertheless, I tend to write it that way at times -- maybe because it : seems so natural to me to ask `do I need to free this thing?' -- and : that gets translated directly to code. I guess I tend to think 'This needs to be freed, let free deal with the details so I won't have to be bothered with them.' Function abstraction is supposed to be about hiding details that don't matter. And in my opinion, this is one of those details. I've also seen code written where this sort of thing was taken to an obscene degree where you'd have 10-30 layers all making the same validity tests to ensure the data was really really good when it was impossible to get down more than a layer or two and have it be bad. Before you say that more tests are good, I cleaned up this mess and was able to reduce 5 overlay regions (yes, 5!) on a pdp-11 fortran monster due to systematically eliminating them (well, I ifdef'd them out (we wrote a fortran preprocessor, but that's another story)). The code went from something like 500k to 225k by removing the redundant tests through all the layers. I know this is an extreme example, but it does go to show that sometimes these tests can be rather signficicant. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message