From owner-freebsd-hackers Mon Dec 18 10:59:18 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 18 10:59:15 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 770A037B402 for ; Mon, 18 Dec 2000 10:59:15 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBIIxCS46046; Mon, 18 Dec 2000 10:59:12 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Dec 2000 10:59:12 -0800 (PST) From: Matt Dillon Message-Id: <200012181859.eBIIxCS46046@earth.backplane.com> To: Warner Losh Cc: "Jacques A. Vidrine" , hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) 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> <200012181840.LAA92561@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: 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. Considering that most people do not call free() with NULL, I don't see much of a reason to optimize the NULL case. Hell, if it were up to me I'd seg fault on trying to free a NULL pointer, but we have to follow the manual page here. The libc malloc/free code assumes that the static ifree() function tests for NULL. To make this change properly you would have to remove the NULL test in ifree() and make sure all callers of ifree() pass only non-NULL pointers, *then* check for your NULL pointer in free(). It would be entirely improper to check for NULL twice, at two different subroutine levels. Optimizations have two sides to them. On the one hand they can make code go faster. On the otherhand they can turn once-readable code into a tangle. The rule of thumb is: If the optimization has no measureable effect on the programs you expect to run in a system, don't do it. Case in point: the TCP stack. Just *try* reading it! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message