Date: Tue, 26 Jun 2001 11:23:23 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: "Jonathan Lemon <jlemon@flugsvamp.com> Alfred Perlstein" <bright@sneakerz.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, "Brian F. Feldman" <green@FreeBSD.org>, Mike Silbersack <silby@FreeBSD.org>, 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: <200106261823.f5QINNM26741@earth.backplane.com> References: <200106261707.f5QH70k41274@green.bikeshed.org> <75438.993576676@critter> <20010626123610.M64836@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:...
:> some particular case of allocation you need the speed of the
:> optimized bzero().
:>
:> But if you need the optimized bzero() that bad, what are you
:> doing calling malloc in the first place ?
:
:We could put the test for size in the macro portion then deciding
:to M_ZERO or not along with which version would be optimized out
:by the compiler for constants.
:
:-Alfred
Yah, but I'm not sure its worth the effort to inline-optimize malloc()
if prezeroing is added. I can see the advantage of optimizing stand-alone
bzero() calls, but inlining certain cases of malloc(M_ZERO) will bloat
the codebase relative to malloc(M_ZERO) (not relative to the bzero that
used to be there, but the code shrink might be more significant). Plus
there is no performance advantage over an optimized zeroing and
malloc(M_ZERO) being able to obtain a pre-zerod block.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106261823.f5QINNM26741>