From owner-freebsd-hackers Mon Dec 18 11:22:50 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 18 11:22:48 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 DCDA937B404 for ; Mon, 18 Dec 2000 11:22: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 eBIJMis08636; Mon, 18 Dec 2000 12:22: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 MAA93045; Mon, 18 Dec 2000 12:22:43 -0700 (MST) Message-Id: <200012181922.MAA93045@harmony.village.org> To: Matt Dillon Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Cc: "Jacques A. Vidrine" , hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 18 Dec 2000 10:59:12 PST." <200012181859.eBIIxCS46046@earth.backplane.com> References: <200012181859.eBIIxCS46046@earth.backplane.com> <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> Date: Mon, 18 Dec 2000 12:22:43 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200012181859.eBIIxCS46046@earth.backplane.com> Matt Dillon writes: : 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. Agreed. It is like teaching a pig to sing. It only annoys you and frustrates the pig :-). Engineering effort is better spend on those parts of the system that take up the most amount of time in your profiles. Otherwise no one will notice. : Case in point: the TCP stack. Just *try* reading it! Agreed. Except back in the dim, dark past the tcp stack did show a rather substantial improvement with the optimizations done to it. I think it was called "fast path" coding where the most common case was made a special case at the top of the loop. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message