From owner-freebsd-hackers Sun Apr 2 06:41:28 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA08854 for hackers-outgoing; Sun, 2 Apr 1995 06:41:28 -0700 Received: from isl.cf.ac.uk (isl-gate.elsy.cf.ac.uk [131.251.22.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA08836 for ; Sun, 2 Apr 1995 06:41:24 -0700 Received: (from paul@localhost) by isl.cf.ac.uk (8.6.9/8.6.9) id OAA19776; Sun, 2 Apr 1995 14:41:36 +0100 From: Paul Richards Message-Id: <199504021341.OAA19776@isl.cf.ac.uk> Subject: Re: Two proposals To: nate@sneezy.sri.com Date: Sun, 2 Apr 1995 14:41:35 +0100 (BST) Cc: Kai.Vorma@hut.fi, hackers@FreeBSD.org In-Reply-To: <199504011746.KAA19377@trout.sri.MT.net> from "Nate Williams" at Apr 1, 95 10:46:00 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1055 Sender: hackers-owner@FreeBSD.org Precedence: bulk In reply to Nate Williams who said > > Is that the CSRI malloc? I wasn't aware of that. As far as slow goes, > benchmarks Righ Murphy did a while ago put it *much* faster than our > current malloc and not much slower than GNU malloc. (And I think once > it was faster than GNU malloc). I'd prefer something that was more > space effecient that wasn't *really* slow vs. something that was a bit > faster but wasn't quite as effecient. Well, one consideration is that if you're running out of memory a more efficient malloc is going to be faster than swapping, even if the malloc itself is a little slower. I seem to run out of memory a lot even with 16Mb and the machine (a P5-90) suddenly slows right down beacuse of all the disk access taking place, more efficient memory usage would probably be a win. -- Paul Richards, FreeBSD core team member. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff.