From owner-cvs-all Sun Jun 24 11:58:45 2001 Delivered-To: cvs-all@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 186E737B401; Sun, 24 Jun 2001 11:58:39 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id 60E365D010; Sun, 24 Jun 2001 13:58:28 -0500 (CDT) Date: Sun, 24 Jun 2001 13:58:28 -0500 From: "Jonathan Lemon Alfred Perlstein" To: Mike Silbersack Cc: Matt Dillon , Mike Silbersack , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, jlemon@FreeBSD.ORG, bmilekic@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_subr.c tcp_timer.c tcp_usrreq.c tcp_var.h Message-ID: <20010624135828.A64836@sneakerz.org> References: <200106231730.f5NHUNd73058@earth.backplane.com> <20010623131152.I23528-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010623131152.I23528-100000@achilles.silby.com>; from silby@silby.com on Sat, Jun 23, 2001 at 01:14:11PM -0500 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Mike Silbersack [010623 13:14] wrote: > > On Sat, 23 Jun 2001, Matt Dillon wrote: > > > Yes, there's no question bzero() should be removed. The subroutine > > overhead alone, never mind it doing anything, is enough to blow away > > any benefit. Hence: > > > > Test3 - man load w/ptrs 35.73 nS/loop > > Test4 - mlptrs & bzero 161.60 nS/loop > > > > Ouch! Of course, us old timers also see the fact that the entire > > subroutine runs dozens of instructions in less then a microsecond and > > say "ooooh, cool...". > > > > -Matt > > Wow! Thanks for the optimization, I hadn't considered that bzero could be > so slow. > > I'm about to take off right now, I'll see if I can mock up some benchmarks > of the overall performance of tcp_output when I get back on Monday. bzero seems to be optimized for large areas, perhaps it would help malloc some if we used some alternative zero'ing function for small allocations with M_ZERO set? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message