Date: Tue, 19 Dec 2000 21:34:32 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: freebsd-hackers@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <20001219213432.B74830@spawn.nectar.com> In-Reply-To: <20001219160152.E79058@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Tue, Dec 19, 2000 at 04:01:52PM -0800 References: <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> <20001218123108.A65143@hamlet.nectar.com> <200012181840.LAA92561@harmony.village.org> <20001218131112.B65143@hamlet.nectar.com> <20001219160152.E79058@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 19, 2000 at 04:01:52PM -0800, David O'Brien wrote: > On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: > > /* Case 1 */ /* Case 2 */ > > if (data) vs. free(data) > > free(data); > > > Actually from an optimization standpoint, #1 can be worse (ie, harder on > the processor). You've got a conditional jump there that is using branch > prediction HW to track (which means there is some other conditional > branch you're not, you're fetching both the taken and not take paths, > etc... If the function call isn't expensive, #2 can be "faster". There's more overhead than just the function call itself. For example, our free() will do some locking & check for recursion beforing calling another function that actually does the work. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org 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?20001219213432.B74830>