From owner-freebsd-hackers Tue Jul 4 09:44:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA29943 for hackers-outgoing; Tue, 4 Jul 1995 09:44:25 -0700 Received: from vinkku.hut.fi (vode@vinkku.hut.fi [130.233.245.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA29936 for ; Tue, 4 Jul 1995 09:44:17 -0700 Received: (from vode@localhost) by vinkku.hut.fi (8.6.11/8.6.7) id TAA24062; Tue, 4 Jul 1995 19:44:06 +0300 Date: Tue, 4 Jul 1995 19:44:06 +0300 Message-Id: <199507041644.TAA24062@vinkku.hut.fi> From: Kai Vorma To: Lars Gerhard Kuehl Cc: FreeBSD-hackers@freefall.cdrom.com Subject: Re: dlmalloc In-Reply-To: <9507041617.AA03378@elbe.desy.de> References: <9507041617.AA03378@elbe.desy.de> Reply-To: Kai.Vorma@hut.fi Sender: hackers-owner@FreeBSD.org Precedence: bulk Lars Gerhard Kuehl writes: > > Does that mean your Xserver is faster with gnumalloc() rather > than with standard malloc(). I've always encountered just the opposite. Okay, not faster, but it used memory better. Try xv with standard malloc, then dlmalloc and finally GNU-malloc. With standard malloc xv grows until it hits datasize limit (16MB) and dies (usually after 10 or so big jpegs). With dlmalloc xv's VZS was about 15MB after last picture of that particular set and with GNU malloc it was about 11MB. The GNU malloc is only malloc I know that can release memory back to the system so it won above contest. It can also be _very_ slow in some situations because it performs many more sbrk calls than others. > Until now I've neither checked it with dlmalloc() nor compiled a profiled > kernel (for it's very likely a general VM problem independent of the > particular malloc implementation, the time is obviously spent in page > allocation). I'll do that probably not before next weekend. dlmalloc is very fast (about as fast as the BSD-malloc) and uses memory efficiently. I mailed some benchmark results some time ago to this list - see mail archives. ..vode