Date: Tue, 26 Jun 2001 19:31:16 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: "Jonathan Lemon <jlemon@flugsvamp.com> Alfred Perlstein" <bright@sneakerz.org>, Mike Silbersack <silby@silby.com>, Matt Dillon <dillon@earth.backplane.com>, 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: <75438.993576676@critter> In-Reply-To: Your message of "Tue, 26 Jun 2001 13:07:00 EDT." <200106261707.f5QH70k41274@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200106261707.f5QH70k41274@green.bikeshed.org>, "Brian F. Feldman" w rites: >Well, I don't get exactly how it would be optimized more than it is now >because it won't be able to take advantage of these "smaller" bzero()s... >unless... what about making malloc() an inline that checks M_ZERO and uses >the new constant-bzero() on sufficiently small sizes after calling malloc >without the M_ZERO? I'm pretty certain GCC would optimize that fine, and >that would buy us the faster-constant-sized-bzero back from the M_ZERO >optimization. I seriously doubt you'd get any optimization out of doing it in general. It would probably be better to _not_ use M_ZERO if in 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 ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?75438.993576676>