Date: Mon, 18 Dec 2000 10:59:12 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Warner Losh <imp@village.org> Cc: "Jacques A. Vidrine" <n@nectar.com>, hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <200012181859.eBIIxCS46046@earth.backplane.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> <200012181840.LAA92561@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012181859.eBIIxCS46046>